Hello, I suspect it has to be one of the external programs adduser calls that is at fault here, and not adduser itself. All of the passwd/group editing programs have to (well, really really should) lock the files before update, and the lock file you see is just that. I see no code in adduser to create a lock file - all the actual changes are done by groupadd and so forth, so probably one of those programs bailed and died, leaving a lock behind. In the particular case of adding a regular user account and also adding a group account, groupadd -g is called to add the group and then useradd is called to create the user and add them to the previously created group. Do you want to reassign this bug to those programs? It seems like the right thing, but I don''t really know the internals of adduser that well yet (I''ve been looking it over yesterday and today). Fortunately, the lock files ''expire'', but it''s still not great to leave them laying around. -- ----------------------------------------------------------------- | ,''''`. Stephen Gran | | : :'' : sgran@debian.org | | `. `'' Debian user, admin, and developer | | `- http://www.debian.org | -----------------------------------------------------------------
Lars Wirzenius
2006-Feb-07 02:48 UTC
[Adduser-devel] Bug#348250: adduser creates /etc/group.lock
ti, 2006-02-07 kello 01:43 +0000, Stephen Gran kirjoitti:> I suspect it has to be one of the external programs adduser calls that is > at fault here, and not adduser itself.Yes, you''re probably right. Reassinging the bug to the passwd package is probably appropriate.> Fortunately, the lock files ''expire'', but it''s still not great to leave > them laying around.Yep. Until they do, however, all packages using adduser tend to fail piuparts testing. Since the existence of the file is due to a bug, I don''t want to add an ignore for it in piuparts, but I''m okay with manually dealing with the failed logs until the bug is fixed.