Or more precisely: "How can I make bash recognise that some user has been added to a group, without rebooting or re-logging-in?

How do you get changes recognised?

For example; I recently added a cd-burner to my old, slow box. (Which -- should it matter -- is for soon-to-be-irrelevent reasons still using a 2.4 kernel) Then I started learning my way around cdrecord.

At first I couldn't even run 'cdrecord -scanbus'. But trying it as 'root' worked.
The 'locate' command found cdrecord in /usr/bin .
'ls -l' shows /usr/bin/cdrecord is owned by user 'root' and group 'cdrom'.
So I tried adding my user to group 'cdrom' in /etc/group. (via 'adduser user group').

Now I appear able to run 'cdrecord ' as an ordinary user, and use tab-completion to enter the command -- but only if I:

• a) Alt-F(n) and login to an unused virtual-console, and work from there, or
• b) use 'exec login' to initiate a new bash shell/session in the current xterm (ie. merely opening a fresh xterm doesn't help).

I realise that I could probably just log out, and re-log-in, but this feels like the near-equivilent of re-booting. Surely there is some more apropriate -- and probably really, really simple -- "unix-y" way to update my configuration, so that my system/bash-shell knows that I'm entitled to run cdrecord?

newgrp cdrom

That doesn't appear to be what I'm looking for. For example, I don't have to log-in to group 'dip' to use pppd (and I no longer remember how that was managed; it was long ago -- I may even have logged-out and back in again. Back then I would have been blindly following directions).

(NOTE: I see that I goofed in my description -- in fact, specifying the full pathname doesn't make any difference. My apologies; I don't know how I managed to make such a blatant mistake. I've now deleted that error.)

Besides, as I mentioned, if I invoke a new login shell (in a text-only console or an xterm), that shell session can find cdrecord. But if I merely open a fresh (non-login) xterm, it doesn't work ("permission denied").

What I'm looking for is a way to make the command available in the current shell, rather than logging out of my current session (including xfce, etc) and logging back in again -- which I'm quite sure would "work", but seems a crude and inelegant way to do things on a Linux system.

Logging in is the moment where linux determines your 'rights' or groups you are in and that will last until you log out.

Why not just log out and log in again. Or if a job is running you don't want to stop for now, start a new bash (if at all that suffices) from a non-login xterm. (which basically is what chgrp does.

At time of login you (or the user logged in) weren't in the group 'cdrom' you won't be until you log out an in again. a reboot, while it will resolve the issue, is not needed at all.

In short, it's by design that you just log out and in again to apply group changes. I am unsure where you would feel where that is equivalent to 'rebooting' a machine.

Not that you will find it any more elegant, but what happens if you su to the current user in, say, an Xterm? For me, this requires the password & then groups shows the recently added group. Inferring from what rhoekstra says, I believe that supplying the password is the key act.

I have to 2nd your annoyance at having to do this. I think that my desktop should be able to stay up for years w/o rebooting -- the same as Linux servers are known to do. In my vocabulary "re-logging-in" to X is a euphemism for "rebooting X". W/ apologies to those who don't see it that way, but for me it's nearly as big a PITA as a true reboot (of the OS).

Restarting X on a desktop is the same as e.g. restarting apache on a server. So servers also don't have an uptime of years in your view.

And there is a big difference between a server and a desktop. A server basically gets configured once while a desktop gets configured at least tens of times because (new) software is installed.

Well, it did'nt sound right that you would need to log out and in again. But I tried it myself, editing /etc/group and adding myself to the "lp" group and running "id -Gn". Then I tried "bash -l", and it still didn't show up. Next I double checked that I had edited /etc/groups correctly by grep'ing for my name. After grep'ing, "lp" showed up.
It was my expectation that the /etc/groups file would be read by the system whenever the permissions need checking. I guess that isn't the case, but I don't understand why reading /etc/groups (with grep) caused the change. Maybe there is a cron job the checks if /etc/groups is changed once a minute or so.

However, adding a user to a group is a rare occurrence so running a login shell or logging out and in again isn't a big deal.

That's interesting. I find the same thing here (except for the delay, which I may have just missed happening. It's a good thing I'm too inexperienced (and/or was too tired) to have remembered about 'bash -l', or I would never have stumbled over 'exec login' while trawling man pages. The difference results from 'bash -l' and 'exec login' is probably a significant clue.


I have tried restarting the desktop via XFCE (Menu > Quit XFwm > Restart), but that didn't help. Is that what you mean?

Is there any way to restart "X" without killing the current desktop session? Despite the inconvenience, I can accept that saving the state of the current desktop is considered to be the desktops' problem, rather than X's. Actually, now I'm wondering if this might partly be an "X" problem, as well as a "bash" problem. But bash doesn't depend on X, so my question still seems relevent.


I'm sure that there is some simple way, presumably to somehow force the shell to re-read the pertinent configuration file(s) and thus incorporate updated info such as changes in "/etc/group" (sort of like doing '. .bashrc' ).
.

Yes, doing 'su user' in an xterm does work.

(Of course, it only works for that particular xterm, and if I exit back into the original shell, then that xterm do longer recognises that the user is a member goup "cdrom").
.

Which is why I find it inelegant.

I believe I have seen daemons which have a "reload" option specifically to tell them to re-read their config files. This is the kind of facility we are looking for.

Needless to say, I don't consider restarting a single daemon anywhere near comparable to restarting X, the Desktop Environment, or the Window Manager.

I'm thinking now this might be more of an "X issue" than a "bash issue".

I seem to recall something similar happening when one changes the hostname. IIRC, changing the hostname from an xterm results in being unable to open any more xterms (at least in that session) until one changes the hostname back to what it was originally.

OK; it's not an X issue.

I tried reloading X (actually, I tried using 'start-stop-daemon' with sinal 1 (SIGHUP) and that didn't work -- it just killed X).

'startx' left me in the same situation as before, so I logged out of X again, and this time logged out of the console session too. After logging back in and restarting X again, the 'cdrecord -scanbus' worked fine (including tab completion). Ergo, my membership in group cdrom is now incorporated into bash's configuration.

So it's definitely a bash issue.

It may have to do with the $GROUPS environmental array variable. I ran into a situation yesterday trying out VitualBox. Even when I added the group using "YaST2 users", it wouldn't start up saying I wasn't a member of the vboxusers group.

There is an environment variable $GROUPS that contains an array of groups that a user is a member of. For graphical apps, the environment is inherited from the users login shell environment. That is what KDE or Gnome uses. I ran in the same situation trying out VirtualBox. Even after running "yast2 users", I couldn't use it because according to the program I wasn't a member of the vboxusers group.

---
Sorry for the dupe. I had hit the Report button by mistake & thought I lost my post.

I think that that's a blind ally. But I had to check it to see why.
I vaugely recall checking that before. Anyways, I have access now that I've done the logout/login dance.

but 'echo $GROUPS' just prints my GID (same as my UID). In other words, it doesn't list any other users (eg. dip, cdrom) that I have group access to.
(I think I'm interpreting that correctly)

When I did 'adduser user group' , I (my user) got added to group "cdrom",
and every user in the /home directory is listed in /etc/group at the end of the /etc/group line for group "dip".
(IIRC, I added some of those via text editor, and some via adduser, back when my system was debian "potato").