From Jonathan Billings on slack https://redhat-internal.slack.com/archives/C05AWLALLP6/p1758897196839339
That thread was not specifically about rhde-build but it describes what I observed a few times while testing the course and dismissed as "human error" in the lack of a better explanation, and because attempting to reproduce it was expensive (creating a new HOL014 classroom and start from scratch). I solved it by reboot workstation. which reinforced the perception I had done something wrong and couldn't find it.
Seems to be a known behavior with systemd-based systems (like RHEL) where systemd reuses an existing session for the new user, so the process environment does NOT get the new user membership.
After logging out and before logging back in, or if you are logged in as another user, use loginctl list-sessions to identify any lingering sessions associated with the user in question. Note the session ID
If you find any sessions belonging to the user that should have been terminated, use loginctl terminate-session <session_id> for each of them
In some cases, processes belonging to the user might still be running even after terminating the session, so you could sudo killall -KILL -u username. Some answers suggest HUP instead of KILL as sufficient, that you dont need to kill the systemd process and others.
https://unix.stackexchange.com/questions/508151/logout-login-not-enough-to-update-group-membership
https://forums.rockylinux.org/t/weird-behavior-with-usermod-and-secondary-group/17247
https://askubuntu.com/questions/1045993/after-adding-a-group-logoutlogin-is-not-enough-in-18-04
Alternatively, use newgrp or sudo to start a new shell with updated froup membership.
https://superuser.com/questions/272061/reload-a-linux-users-group-assignments-without-logging-out
https://stackoverflow.com/questions/49434650/how-to-add-a-user-to-a-group-without-logout-login-bash-script
From Jonathan Billings on slack https://redhat-internal.slack.com/archives/C05AWLALLP6/p1758897196839339
That thread was not specifically about rhde-build but it describes what I observed a few times while testing the course and dismissed as "human error" in the lack of a better explanation, and because attempting to reproduce it was expensive (creating a new HOL014 classroom and start from scratch). I solved it by reboot workstation. which reinforced the perception I had done something wrong and couldn't find it.
Seems to be a known behavior with systemd-based systems (like RHEL) where systemd reuses an existing session for the new user, so the process environment does NOT get the new user membership.
After logging out and before logging back in, or if you are logged in as another user, use loginctl list-sessions to identify any lingering sessions associated with the user in question. Note the session ID
If you find any sessions belonging to the user that should have been terminated, use loginctl terminate-session <session_id> for each of them
In some cases, processes belonging to the user might still be running even after terminating the session, so you could sudo killall -KILL -u username. Some answers suggest HUP instead of KILL as sufficient, that you dont need to kill the systemd process and others.
https://unix.stackexchange.com/questions/508151/logout-login-not-enough-to-update-group-membership
https://forums.rockylinux.org/t/weird-behavior-with-usermod-and-secondary-group/17247
https://askubuntu.com/questions/1045993/after-adding-a-group-logoutlogin-is-not-enough-in-18-04
Alternatively, use newgrp or sudo to start a new shell with updated froup membership.
https://superuser.com/questions/272061/reload-a-linux-users-group-assignments-without-logging-out
https://stackoverflow.com/questions/49434650/how-to-add-a-user-to-a-group-without-logout-login-bash-script