System crash in guest session locks /etc/passwd forever

Thanks for your report. I'd need more information to fix it. Have you tried different Real names, i.e. do some characters trigger the problem, and others not? Did you try changing the Real name of several users (e.g. create a test user and try changing its Real name)?

If none of those tests bring more information, please run:
sudo killall /usr/bin/perl
sudo /usr/share/system-tools-backends-2.0/scripts/SystemToolsBackends.pl -m UsersConfig --platform ubuntu-8.04 -v

and reproduce the procedure without stopping the program. Then please attach the output here. Thanks!

Trying to add new user with users-admin, the newly created user doesn't exist after restarting the app.

then the output of when trying to change own name.

begin::Start of work report.
file_locate_tool_success::Found tool [uname].
file_run_pipe_success::Piping command [LC_ALL=C PATH=$PATH:/sbin:/usr/sbin /bin/uname -s 2> /dev/null |] for reading.
file_locate_tool_success::Found tool [usermod].
file_locate_tool_success::Found tool [userdel].
file_locate_tool_success::Found tool [useradd].
file_locate_tool_success::Found tool [adduser].
file_locate_tool_success::Found tool [deluser].
file_locate_tool_success::Found tool [chfn].
file_locate_tool_failed::Couldn't find tool [pw].
file_open_read_success::Reading options from [/etc/pam.d/passwd].
file_open_read_success::Reading options from [/etc/pam.d/common-password].
file_open_read_success::Reading options from [/etc/login.defs].
file_open_read_success::Reading options from [/etc/passwd].
file_open_read_success::Reading options from [/etc/shadow].
file_open_read_success::Reading options from [/etc/shells].
file_create_path::Directory [//var/cache/system-tools-backends/backup///1/] created.
file_backup_rotate::Backup directory [//var/cache/system-tools-backends/backup//] was rotated.
file_create_path::Directory [//var/cache/system-tools-backends/backup///1//etc/master.passwd] created.
file_backup_success::Saved backup for [//var/cache/system-tools-backends/backup//].
file_open_read_success::Reading options from [/etc/passwd].
file_open_read_success::Reading options from [/etc/shadow].
file_run::Running command [LC_ALL=C PATH=$PATH:/sbin:/usr/sbin /usr/sbin/usermod -d '/home/tta' -g '1000' -l 'tta' -p '$6$IaecseZ9$uS3fwauD1ULN0S.23buiaUhH9SIP.XbR1afdUfbXoEUkHzeJOHRbPCyTiz1jzMJcGO7M7vscUjFHGg7KP9atZ1' -s '/bin/bash' -u '1000' 'tta' 2> /dev/null > /dev/null].
file_run::Running command [LC_ALL=C PATH=$PATH:/sbin:/usr/sbin /usr/sbin/usermod -c 'Tuomas Aavikko,,,,' tta 2> /dev/null > /dev/null].
file_buffer_load::Loading file [/etc/shells] to buffer.
file_open_read_success::Reading options from [/etc/shells].
file_buffer_save::Saving buffer to file [/etc/shells].
file_open_write_success::Writing to [/etc/shells].
file_create_path::Directory [/etc/shells] created.
replace_split::Replacing key [UID_MIN] in [/etc/login.defs].
file_buffer_load::Loading file [/etc/login.defs] to buffer.
file_open_read_success::Reading options from [/etc/login.defs].
file_buffer_save::Saving buffer to file [/etc/login.defs].
file_open_write_success::Writing to [/etc/login.defs].
file_create_path::Directory [/etc/login.defs] created.
replace_split::Replacing key [UID_MAX] in [/etc/login.defs].
file_buffer_load::Loading file [/etc/login.defs] to buffer.
file_open_read_success::Reading options from [/etc/login.defs].
file_buffer_save::Saving buffer to file [/etc/login.defs].
file_open_write_success::Writing to [/etc/login.defs].
file_create_path::Directory [/etc/login.defs] created.
file_open_read_success::Reading options from [/etc/pam.d/passwd].
file_open_read_success::Reading options from [/etc/pam.d/common-password].
file_open_read_success::Reading options from [/etc/login.defs].
file_open_read_success::Reading options from...

Thanks! From the logs, I don't see why it does not work. Could you run
sudo /usr/sbin/usermod -c 'Tuomas Aavikko,,,,' tta
and see if that works?

2009/9/20 Milan Bouchet-Valat <email address hidden>

> Thanks! From the logs, I don't see why it does not work. Could you run
> sudo /usr/sbin/usermod -c 'Tuomas Aavikko,,,,' tta
> and see if that works?
>
>
tta@dv5:~$ sudo /usr/sbin/usermod -c 'Tuomas Aavikko,,,,' tta
usermod: cannot lock /etc/passwd; try again later.

The $HOME is encrypted via ecryptfs option in the installer, does it make a
difference?

Good, we know have the original error. I don't know what can trigger this, but the problem is not specific to the gnome-system-tools.

Please run 'sudo apt-get install lslk' and
lslk /etc/passwd
It seems that another process/user is locking the file, preventing us from editing it. Sure, we should report errors instead of failing silently, but that's another story.

I don't think encrypted home changes anything to the problem, since the file is on the root partition.

2009/9/20 Milan Bouchet-Valat <email address hidden>

> Good, we know have the original error. I don't know what can trigger
> this, but the problem is not specific to the gnome-system-tools.
>
> Please run 'sudo apt-get install lslk' and
> lslk /etc/passwd
> It seems that another process/user is locking the file, preventing us from
> editing it. Sure, we should report errors instead of failing silently, but
> that's another story.

There seems to be no locks...

tta@dv5:~$ lslk /etc/passwd
tta@dv5:~$ sudo lslk /etc/passwd
lslk: WARNING: can't stat() fuse.gvfs-fuse-daemon file system
/home/tta/.gvfs
      Output information may be incomplete.

> I don't think encrypted home changes anything to the problem, since the
> file is on the root partition.
>
>
Was just wondering could ecryptfs somehow block the writing of user specific
info.

I'm running out of ideas then, that's not really my domain... Maybe something in your configuration prevents usermod from locking the file, even if no process is using it. Can you remember something you did before user creation became impossible? eCryptfs could explain it if the root partition was encrypted, but I don't think the option you chose does this.

Moving the task against usermod, since the gnome-system-tools can't do much here.

2009/9/20 Milan Bouchet-Valat <email address hidden>

> I'm running out of ideas then, that's not really my domain... Maybe
> something in your configuration prevents usermod from locking the file,
> even if no process is using it. Can you remember something you did
> before user creation became impossible? eCryptfs could explain it if the
> root partition was encrypted, but I don't think the option you chose
> does this.
>

I haven't done any tweaking which might affect this.
Only fiddled with xorg-edgers and fglrx-drivers.

At installation used manual partitioning.

Desktop system is running 9.10 KDE and kuser is working correctly, being
able to change the name.
So it seems it is GNOME specific issue.

This bug does not seem to be GNOME specific since the problem happens in usermod. Maybe KDE does not use usermod.

Have you tried running the usermod commandline from a fresh boot, i.e. before you tried to edit the user with users-admin? Maybe that's the program that is locking /etc/passwd (via the backends).

As lslk did not return anything, could you try 'fuser /etc/passwd' too?

2009/9/20 Milan Bouchet-Valat <email address hidden>

> This bug does not seem to be GNOME specific since the problem happens in
> usermod. Maybe KDE does not use usermod.
>

Tested usermod in KDE setup in konsole, it worked.
This computer is running Karmic upgraded from Jaunty

> Have you tried running the usermod commandline from a fresh boot, i.e.
> before you tried to edit the user with users-admin? Maybe that's the
> program that is locking /etc/passwd (via the backends).
>

Yes, newest attempt was moments ago with up-to-dated and restarted GNOME.
usermod fails, with previous errors.
this computer is running cleanly installed Karmic.

> As lslk did not return anything, could you try 'fuser /etc/passwd' too?

No output from this, nothing is using the file.

Small detail noticed, in KDE the /etc/passwd does not include ",,," after
the real name.
like wise: devil:x:1000:1000:Tuomas Aavikko:/home/devil:/bin/bash

but in GNOME: tta:x:1000:1000:tta,,,:/home/tta:/bin/bash

ps. sorry for late response, stupid work :)

My understanding of your comment is that you tested KDE and GNOME on two different machines. That easily explains why one can work and not the other, ignoring the desktop environment difference.

The difference with ",,," should not be a problem, it simply comes from the code in the backends that always print thos, even when the fields are empty. That should not be a problem, and the error seems to happen before usermod even reads the file.

Now we would need the help from somebody more familiar with usermod's codebase. Maybe reporting the bug to Debian could be good.

Just an idea: do you happen to be using some strange file system on your root partition, or specific mount option? I don't know whether that could affect file locks, but...

2009/9/23 Milan Bouchet-Valat <email address hidden>

> Just an idea: do you happen to be using some strange file system on your
> root partition, or specific mount option? I don't know whether that
> could affect file locks, but...

Ext4 for all my partitions, /home encrypted, nothing else special.
tta@dv5:~$ mount
/dev/sda1 on / type ext4 (rw,errors=remount-ro)
none on /proc type proc (rw)
none on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
udev on /dev type tmpfs (rw,mode=0755)
none on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
none on /dev/shm type tmpfs (rw,nosuid,nodev)
none on /var/run type tmpfs (rw,nosuid,mode=0755)
none on /var/lock type tmpfs (rw,noexec,nosuid,nodev)
none on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
/dev/sda2 on /home type ext4 (rw)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc
(rw,noexec,nosuid,nodev)
/home/tta/.Private on /home/tta type ecryptfs
(ecryptfs_sig=xxxxxxxxxxxxx,ecryptfs_fnek_sig=xxxxxxxxxxxxx,ecryptfs_cipher=aes,ecryptfs_key_bytes=16)
gvfs-fuse-daemon on /home/tta/.gvfs type fuse.gvfs-fuse-daemon
(rw,nosuid,nodev,user=tta)

Tried to add new user:
tta@dv5:~$ sudo adduser test
[sudo] password for tta:
Adding user `test' ...
Adding new group `test' (1001) ...
Adding new user `test' (1001) with group `test' ...
useradd: cannot lock /etc/passwd; try again later.
adduser: `/usr/sbin/useradd -d /home/test -g test -s /bin/bash -u 1001 test'
returned error code 1. Exiting.
tta@dv5:~$

2009/9/26 Tuomas Aavikko <email address hidden>
>
> Tried to add new user:
> tta@dv5:~$ sudo adduser test
> [sudo] password for tta:
> Adding user `test' ...
> Adding new group `test' (1001) ...
> Adding new user `test' (1001) with group `test' ...
> useradd: cannot lock /etc/passwd; try again later.
> adduser: `/usr/sbin/useradd -d /home/test -g test -s /bin/bash -u 1001
> test' returned error code 1. Exiting.
> tta@dv5:~$
>

And then on my KDE setup
devil@core7:~$ sudo adduser test
[sudo] password for devil:
Adding user `test' ...
Adding new group `test' (1001) ...
Adding new user `test' (1001) with group `test' ...
Creating home directory `/home/test' ...
Copying files from `/etc/skel' ...
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
Changing the user information for test
Enter the new value, or press ENTER for the default
        Full Name []: testing tester
        Room Number []:
        Work Phone []:
        Home Phone []:
        Other []:
Is the information correct? [Y/n] y
devil@core7:~$

So passwd is b0rked on fresh installation (tried reinstalling it)
But upgrade from Jaunty is working correctly.

I have also encountered this bug and tried to nail it down. It seems like the following files have been left:

/etc/passwd.lock
/etc/passwd+
/etc/shadow.lock

I renamed these files and now I can successfully create users again.

Out of curiosity, I checked what was in the passwd+ file, the result was:

< guest:x:115:123:Guest,,,:/:/bin/bash
---
> guest:x:115:123:Guest,,,:/tmp/guest-home.t4xKqt:/bin/bash

...it seems like this was left from a (crashed/hung?) attempt to make a guest session.

2009/10/10 David Henningsson <email address hidden>

> I have also encountered this bug and tried to nail it down. It seems
> like the following files have been left:
>
> /etc/passwd.lock
> /etc/passwd+
> /etc/shadow.lock
>
> I renamed these files and now I can successfully create users again.
>

Confirmed.
By removing these .lock files I can change my name, with usermod or
users-admin.
this also fixes my ability to start guest-session.

We need to track down the program that has left those locks when crashing. Is it gdm-guest-session itself, or is it using a program to change /etc/passwd (possibly usermod itself)?

2009/10/10 Milan Bouchet-Valat <email address hidden>

> We need to track down the program that has left those locks when
> crashing. Is it gdm-guest-session itself, or is it using a program to
> change /etc/passwd (possibly usermod itself)?
>

As of now, guest-session doesn't leave any locks behind.between the
commands, I launched guest-session.

tta@dv5:~$ ls -l /etc/{passwd,shadow}*
-rw-r--r-- 1 root root 1685 2009-10-10 08:12 /etc/passwd
-rw------- 1 root root 1743 2009-10-10 08:12 /etc/passwd-
-rw-r----- 1 root shadow 1042 2009-10-10 08:12 /etc/shadow
-rw------- 1 root root 1069 2009-09-08 21:50 /etc/shadow-
tta@dv5:~$ ls -l /etc/{passwd,shadow}*
-rw-r--r-- 1 root root 1685 2009-10-10 15:43 /etc/passwd
-rw------- 1 root root 1743 2009-10-10 15:41 /etc/passwd-
-rw-r----- 1 root shadow 1042 2009-10-10 15:43 /etc/shadow
-rw------- 1 root root 1069 2009-10-10 15:41 /etc/shadow-

I can reproduce the bug by starting rythmbox in the original session (and have it play something) and then try to switch to a guest session. At that point, my system locks up hard and I can't do anything but doing a hard reset (Ctrl-Alt-F1, Ctrl-Alt-REISUB does not work). After the reboot the lock files are present.

As a side note, this could be video driver related (I'm using open source ATI drivers), as a thin line of blue and green dots in the middle is all that's showing on the screen at that time.

Interesting. Could you report another bug about that crash in xserver-xorg? That's probably the place where the bug occurs. See https://wiki.ubuntu.com/X/Troubleshooting/Freeze.

This report can be kept to determine why crashing while a guest session is open will leave those files. That's a real issue on the long term - even if the system should not crash...

2009/10/11 David Henningsson <email address hidden>

> I can reproduce the bug by starting rythmbox in the original session
> (and have it play something) and then try to switch to a guest session.
> At that point, my system locks up hard and I can't do anything but doing
> a hard reset (Ctrl-Alt-F1, Ctrl-Alt-REISUB does not work). After the
> reboot the lock files are present.
>

could not reproduce.
tested with totem & rhythmbox
one at a time, file was playing and launched a guest-session.
Logged out, and resumed the normal session fine with the file still playing.

> As a side note, this could be video driver related (I'm using open
> source ATI drivers), as a thin line of blue and green dots in the middle
> is all that's showing on the screen at that time.
>

Same here, radeon driver in use with HD3450

Tuomas: it's very unlikely that you experienced the very same crash. That's why I asked David to report a separate bug. Here, we just deal with the troubles that appear after a crash in guest session, disregarding its causes.

gdm-guest-session calls adduser, which creates those lock files.

Do you mean that adduser likely crashed when you called it, leaving those lock files? What's the kind of call you're passing to it? adduser in Debian doesn't seem to be very responsive to our bug reports, so we may need to fix it ourselves...

> adduser in Debian doesn't seem to be very responsive to our bug reports, so we may need to fix it ourselves...

Whether this will be fixed by yourselves or by Debian, the problem need to be understood first.

Is there a way to reproduce the issue? Does anybody have an idea if this lock file was really left by useradd?

The lock files are actually created by useradd, but they should also be removed by useradd.

Note that after a system crash anything could happen. useradd might have been killed between the creation of the lock file and its removal. In that case, the lock file is a feature which indicate to the user that the system files should be checked.

The only bug I can see in this bug report is that the actual message "cannot lock /etc/passwd" is not displayed to the end user and the usermod failure seems to be ignored silently.

I guess the issue is hard to reproduce, but we've already 3 duplicates of this. The likelyhood that the system crashes at the very moment useradd is modifying /etc/passwd is so tiny that I immediately thought there was some special casing for gdm-guest-session, e.g. blocking /etc/passwd while the guest session is open. I may well be wrong, though. The other explanation would be that when gdm-guest-session makes the system crash, it often happens at a point where useradd is just starting - this could be improved by waiting for it to return. Just guessing.

The reporting problem is well-known, and on my TODO list, hopefully for Lucid. But it won't be very user-friendly anyways, most people don't know what this means: it took me some time to discover what that lock was. So improving error reporting won't be enough.

A workaround could be to remove the lock files on bootup.

And btw, with my current Karmic with the latest updates, I cannot reproduce it anymore.

The goal of the lock files is to protect users from doing something wrong when system files might be in an inconsistent state.

Removing the lock files at boot time would definitely avoid the issue pointed in this bug report, but would mean "there is probably something wrong with the system files, it's probably safer not to warn anybody. Let's start hiding the evidence that there might be something wrong."

Therefore,I would not recommend to touch these lock files, even after checking the files with pwck or grpck. Only human being can do so because only human being might remember what leaded to such possible inconsistency.

The possible solutions might be:
 * reduce the time between lock file creation and lock file removal in the shadow utils (I don't think this is possible)
 * avoid changing the passwd file too often (would it be possible to have static home directory for guest?)
 * indicate the failures and cause for failure. (note that a syslog checker would probably already notify the administrators in this case).

David: do you mean you have been able to reproduce it before Karmic? How? That could mean that the main cause of the lock files being left on the disk would have disappeared, which is good news.

@Milan: It was present in Karmic beta but not in Karmic final. I think it went away with kernel v 2.6.31-14, but I'm not certain.

@Nicolas: Hmm...point taken, but I would say it depends then. In a debug version of Ubuntu, we should probably leave it for examination; but in a release version, we should make things as comfortable for the user as possible, and recover from every error in the best possible way.

I tried installing openssh-server and it failed on
useradd: cannot lock /etc/passwd; try again later.
I then found this bug report and after renaming passwd.lock, passwd+ and shadow.lock I could install openssh-server without any problems.

My system crashes when I try to run a guest session. I have had this problem since 8.10. I am running Karmic 64 now (clean install). It has something to do with my ATI HD 2400 PRO graphics card I think. I have tried getting a guest session once on Karmic just to see if the issue has been fixed. It crashed again. I guess that is where these locks came from.

I'm with Karmic 64bit and like @Stapel with ati graphics. I had same problem with openssh-server package. Package installed without problem after renaming files.

Long time no see answers to this problem. I have it in a newer distribution:

Linux xxx 3.0.0-14-generic #23-Ubuntu SMP Mon Nov 21 20:28:43 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux

I was changing the main group of my login with "usermod -g newgroup user". Later, I did erase the old group. The operation apparently finished well. But after restarting, my login does have only the newgroup, I lost my root privileges so modifications from the session have been impossible.

I tried starting from recovery mode, and couldn't add group to my login because couldn't lock file /etc/passwd. Checking I found this bug, and could check in my system the existence of

-rw-r--r-- 1 root root 1929 2012-01-07 20:28 /etc/passwd
-rw------- 1 root root 1928 2012-01-07 20:20 /etc/passwd-
-rw-r----- 1 root shadow 1279 2012-01-07 17:48 /etc/shadow
-rw------- 1 root root 1250 2012-01-05 23:27 /etc/shadow-

I tried erasing such *- files aka passwd- and shadow-, from recovery session as root, only got message telling me the files are read only.

Any workarounds ? cheers.

Check with 'mount' that / isn't mounted read-only. The best option is probably to set a root password by running 'passwd' as root user in recovery mode, and then to reboot in normal mode, log in as root, and add your user to the sudoers group.

Status changed to 'Confirmed' because the bug affects multiple users.

I encountered this problem after a Guest session crashed on Xubuntu 12.04 (Precise Pangolin) amd64/x86_64. The crash was probably due to a fglrx bug but /etc/group.lock kept users-admin and adduser from adding any new users.

i'm using ubuntu12.10 and i had the same bug that affects a lot of users (can't install or update any paquet that uses addgroup, adduser)
i tried "sudo rm /etc/{passwd,group,shadow}.lock" =>the same bug
then "fuser /etc/group" =>nothing
then "fuser /etc/passwd" => there was "cupsd" and "colord-sane"
then, i stopped only "colord-sane" by "killall colord-sane" because i didn't find it on " sudo gnome-system-monitor" =>but, the same bug
so, i tried again "sudo rm /etc/{passwd,group,shadow}.lock" to delete the new log files ('group.lock' and 'shadow.lock')
then "fuser /etc/passwd" =>nothing (even "cupsd")

so, i tried to create a new user and new group and every thing was Ok (no bug) also, i'm now able to install paquets that use add{user,group} :-)

I'm not sure if "colord-sane" was the problem, but i found many bug reports about it and also this: http://iso.qa.ubuntu.com/qatracker/reports/bugs/1026520
also, some other things i thought that may caused this problem :
-open guest sessions many times and sometimes i tried to "sudo *" command but i'm not sure because after i fixed the problem, i tried opening guest session 3 times but every thing is ok even after trying "sudo *" command on guest session
-opening root session for a long time (3 mounth). but can this be the problem (virus, permissions,...)?
-issues with the hardware of my graphic card nVidia (no software/driver issuses even i'm using nouveau driver from the daily build) that causes some problems with 3D apps and some color problems. but, the bug wasn't due to this hardware issues as i think