Hi,
On F12, as of about 1 month ago, user information started getting lost sometimes after resuming from hibernate. You can see this as follows:
- With new terminals, the prompt user name is "I have no name!". - With new SSH sessions, you get "You don't exist, go away!" - "Su" fails with "su: user root does not exist" - You can't login from new VTYs (just fails) - "ls" does not look up uids/gids
/etc/passwd is 644, and usernames do exist there. LDAP auth is not used. Selinux is permissive. nscd is off. I do use fingerprint reader for auth but I doubt that's relevant.
I couldn't find anything in bugzilla, and I have no idea which component to file this against. Any ideas?
On Tue, 2010-05-04 at 07:27 +0300, Pekka Savola wrote:
On F12, as of about 1 month ago, user information started getting lost sometimes after resuming from hibernate. You can see this as follows:
- With new terminals, the prompt user name is "I have no name!".
- With new SSH sessions, you get "You don't exist, go away!"
- "Su" fails with "su: user root does not exist"
- You can't login from new VTYs (just fails)
- "ls" does not look up uids/gids
/etc/passwd is 644, and usernames do exist there. LDAP auth is not used. Selinux is permissive. nscd is off. I do use fingerprint reader for auth but I doubt that's relevant.
I couldn't find anything in bugzilla, and I have no idea which component to file this against. Any ideas?
Run "strace id" and see if it is able to open and read /etc/nsswitch.conf and /etc/passwd. If so, it would be a glibc bug. If not, investigate why those files cannot be read.
On 05/04/2010 12:34 AM, Matt McCutchen wrote:
On Tue, 2010-05-04 at 07:27 +0300, Pekka Savola wrote:
On F12, as of about 1 month ago, user information started getting lost sometimes after resuming from hibernate. You can see this as follows:
- With new terminals, the prompt user name is "I have no name!".
- With new SSH sessions, you get "You don't exist, go away!"
- "Su" fails with "su: user root does not exist"
- You can't login from new VTYs (just fails)
- "ls" does not look up uids/gids
/etc/passwd is 644, and usernames do exist there. LDAP auth is not used. Selinux is permissive. nscd is off. I do use fingerprint reader for auth but I doubt that's relevant.
I couldn't find anything in bugzilla, and I have no idea which component to file this against. Any ideas?
Run "strace id" and see if it is able to open and read /etc/nsswitch.conf and /etc/passwd. If so, it would be a glibc bug. If not, investigate why those files cannot be read.
You mention LDAP auth. Do you have users on the system handled by LDAP? If so, make sure that in /etc/nsswitch.conf on the passwd line that "files" comes before "ldap" (or SSSD, if you're using that).
If something other than "files" is listed first, it could be returning an error that's preventing it from trying /etc/passwd.
If "files" is listed first, then Matt is right, and it's either a permissions problem on /etc/passwd or /etc/nsswitch.conf, or a bug in glibc.
The fact that it only happens after hibernate is what leads me to think it might be related to ldap lookups. (Where the LDAP connection would have dropped during the hybernation)
On Tue, 4 May 2010, Stephen Gallagher wrote:
Run "strace id" and see if it is able to open and read /etc/nsswitch.conf and /etc/passwd. If so, it would be a glibc bug. If not, investigate why those files cannot be read.
You mention LDAP auth. Do you have users on the system handled by LDAP? If so, make sure that in /etc/nsswitch.conf on the passwd line that "files" comes before "ldap" (or SSSD, if you're using that).
If something other than "files" is listed first, it could be returning an error that's preventing it from trying /etc/passwd.
If "files" is listed first, then Matt is right, and it's either a permissions problem on /etc/passwd or /etc/nsswitch.conf, or a bug in glibc.
The fact that it only happens after hibernate is what leads me to think it might be related to ldap lookups. (Where the LDAP connection would have dropped during the hybernation)
I haven't been able to see this problem again, but in nsswitch.conf passwd, shadow and group are all just "files". There's no ldap anywhere. netgroup and publickey are by default 'nisplus' and a bit similar for bootparams. automount/aliases 'files nisplus'. So I doubt LDAP is the cause.
After a lot of hibernate/resume attempts I have sometimes seen weird stuff (like every command segfaulting) but I hope it's irrelevant for this specific case.