What the POSIX id Command Actually Shows

I was setting up QEMU/KVM on a Debian Trixie box so I could run virt-manager without typing sudo for every little thing. That means adding yourself to the libvirt and kvm groups:

sudo usermod -aG libvirt,kvm benjamin

Standard advice everywhere says the same thing: log out, log back in, and the new groups will be active. So I did. virt-manager still couldn’t talk to the hypervisor. I ran id to sanity-check my groups, and libvirt and kvm just weren’t there.

My first assumption was that the usermod had silently failed. It hadn’t:

grep -E '^(libvirt|kvm)' /etc/group

libvirt:x:998:benjamin
kvm:x:107:benjamin

The output confirms that I was in both groups. /etc/group knew it. id insisted I wasn’t. Re-running usermod said I was already a member. Logging out and back in again did nothing. Only a full reboot made id agree with /etc/group.

id Doesn’t Read /etc/group

I had never taken a close look at the id tool. It doesn’t open /etc/passwd or /etc/group and print what it finds. It asks the kernel what identity is attached to the current process — the real and effective user and group IDs, plus supplementary groups, that were assigned to your session when it started.

The POSIX specification for id says as much directly: with no arguments, id “shall write the user and group IDs and the corresponding user and group names of the invoking process.” Invoking process — not “whatever’s currently in the group database.”

That info clicked for me. A shell’s group membership is set once, when the session’s login process starts (traditionally by login, or whatever authenticates your session on your desktop environment). Editing /etc/group afterward doesn’t retroactively change a token that was already handed to a running process. It only changes what new sessions will get.

Why Logout/Login Didn’t Fix It, But a Reboot Did

This is the part that confused me most, because “log out and back in” is the standard fix you’ll see recommended for exactly this problem, and it usually works. On this Debian install, whatever was keeping my desktop session’s authentication agent alive across logout — a persistent systemd --user instance, an agent that wasn’t fully torn down, something in that neighborhood — meant my “new” session wasn’t actually starting a fresh login from scratch. The old process identity carried over.

A reboot leaves no way for anything to survive: every process, including whatever spawns your login session, starts over and re-reads group membership from scratch. That’s a blunter tool than it should have to be, but it’s a guaranteed one.

The lesson isn’t “always reboot instead of logging out.” It’s that “log out and back in” is really shorthand for “start a new session whose process identity gets initialized fresh from /etc/group” — and on some systems, some setups, that shorthand doesn’t hold.

Not a Linux Thing

Worth calling out: none of this is Linux-specific behavior bolted on by GNU coreutils. id is POSIX standard — the same command, the same semantics, on Linux, macOS, the BSDs, Solaris, AIX. Every one of them is reporting kernel-level process identity, not consulting a database file live. If you’ve ever wondered why changing a user’s group doesn’t seem to “take” until something forces a new login, this is why, wherever you’re running it.

If you want the precise wording, the Open Group’s Base Specifications entry for id is short and worth the two minutes.