FS#27984 - [initscripts] System hangs at boot on "Removing Leftover Files"

Attached to Project: Arch Linux
Opened by Laurent Rahuel (asrenzo) - Wednesday, 18 January 2012, 11:19 GMT
Last edited by Tom Gundersen (tomegun) - Tuesday, 08 May 2012, 12:49 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Dave Reisner (falconindy)
Tom Gundersen (tomegun)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 4
Private No



Since my friday upgrade, systems hangs for a while (several minutes) at this point.
My box is configured to auth against an external ldap server.
When this system is finally up, everything is OK.
Digging around system boot process, I found that the problem must be located in /usr/lib/initscripts/arch-tmpfiles.
When I comment this line in function remove_leftover from file /etc/rc.d/functions, eveything is OK.

In file /usr/lib/tmpfiles.d/consolekit.conf, we have no username nor groupname provided.
Then arch-tmpfiles adds default values for uid and gid. These values are 0 and 0.

But when using uid numbers instead of usernames, the getent command requires the ldap connexion to be up.
This can not be effective because network is not up.

Thus replacing content of /usr/lib/tmpfiles.d/consolekit.conf with
d /run/ConsoleKit 0755 root root -

instead of
d /run/ConsoleKit 0755 - - -
does the trick.


This task depends upon

Closed by  Tom Gundersen (tomegun)
Tuesday, 08 May 2012, 12:49 GMT
Reason for closing:  No response
Comment by Julian (nospoonuser) - Saturday, 21 January 2012, 12:44 GMT
i can confirm this bug !
Comment by Tom Gundersen (tomegun) - Saturday, 21 January 2012, 12:51 GMT
Should be fixed either in ldap or in consolekit package. Dave had an opinion, so added him.
Comment by Dave Reisner (falconindy) - Saturday, 21 January 2012, 14:41 GMT
Seems like a broken LDAP setup, to me. Why aren't you caching UIDs/GIDs in /etc/netgroup?
Comment by Marek Kozlowski (guayasil) - Wednesday, 01 February 2012, 17:50 GMT
The same problem :-(
The workaround works; thanks!
Comment by Tom Gundersen (tomegun) - Thursday, 02 February 2012, 16:06 GMT
Looks like NOTABUG to me, your system needs to be configured correctly (i.e. not require network connections to look up system users/groups).
Comment by Laurent Rahuel (asrenzo) - Wednesday, 08 February 2012, 16:25 GMT
man netgroup:

The netgroup file specifies ``netgroups'', which are sets of (host, user, domain) tuples that are to be given similar network access.

Each line in the file consists of a netgroup name followed by a list of the members of the netgroup. Each member can be either the name of another netgroup or a specification of a tuple as follows: (host, user, domain)

Moreover, as of every howto dealing with ldap authentication on linux, the official archlinux one (https://wiki.archlinux.org/index.php/LDAP_Authentication) requiers to modify /etc/nsswitch.conf to lookup group in ldap after files.
Comment by Tom Gundersen (tomegun) - Wednesday, 08 February 2012, 16:28 GMT
Laurent: I don't know exactly what you are trying to say, could you explain again?

The point is that you must configure your machine to not require network connection to resolve system users/groups, this is not supported.
Comment by Laurent Rahuel (asrenzo) - Friday, 10 February 2012, 17:01 GMT

I just want to say that it doesn't seems to be related to configuration. Even if users and groups are supposed to be checked in files before ldap in nsswitch.conf, the fact that when uid or gid are not found in parsed files, they are replaced by numbers (0,0) in /usr/lib/initscripts/arch-tmpfiles. Then getent passwd 0 (or getent group 0) will check in both files and ldap.

Then if network is not up and ldap server is not on the same machine, the system hangs.

One simple action is to change these lines from /usr/lib/initscripts/arch-tmpfiles

[[ ${line[3]} = '-' ]] && line[3]=0
[[ ${line[4]} = '-' ]] && line[4]=0


[[ ${line[3]} = '-' ]] && line[3]='root'
[[ ${line[4]} = '-' ]] && line[4]='root'

Comment by Tom Gundersen (tomegun) - Wednesday, 21 March 2012, 13:49 GMT
Please confirm whethre or not this is still an issue with initscripts-2012.03.1-1.
Comment by Paolo (peoro) - Saturday, 14 April 2012, 17:02 GMT
This is still an issue with initscripts 2012.03.2-1 .
Using the solution proposed by Laurent Rahuel (asrenzo) works.
Comment by Laurent Rahuel (asrenzo) - Tuesday, 17 April 2012, 15:15 GMT
I confirm. I installed a base system with stock iso. Configured to auth against an LDAP server. Rebooted and eveything was OK.
Then I upgraded the system and system hangs on boot with the same message.
Comment by Laurent Rahuel (asrenzo) - Monday, 07 May 2012, 09:19 GMT
  • Field changed: Percent Complete (100% → 0%)
This issue is still not fixed as I mentionned in my last post.

I have more than 25 boxes which are all broken after an upgrade embeding initscripts if I forget to manually fix consolekit.conf.

Could you please fix and TEST before closing.


Laurent Rahuel
Comment by Tom Gundersen (tomegun) - Monday, 07 May 2012, 09:26 GMT
@Laurent: your last post was made two releases ago. Can you confirm that this is still a problem with 2012.05.1? If so, can you point out what's wrong with the patch I applied: http://projects.archlinux.org/initscripts.git/commit/?id=acfbe4b8e05959079a807dcc1df7650946cd0924. I have no way of testing this stuff as I don't have the right setup. If you want it to work, leave the attitude and post a patch to arch-projects@archlinux.org.
Comment by Laurent Rahuel (asrenzo) - Monday, 07 May 2012, 09:36 GMT

Very strange.

pacman -Ss initscripts will return even if i upgraded my system with pacman -Suy last week

core/initscripts 2012.05.1-1 (base) [installé: 2012.03.2-1]
System initialization/bootup scripts

I had to force install with "pacman -S initscrpts" to get the latest version with your changes.

Any clue ?


Laurent Rahuel
Comment by Tom Gundersen (tomegun) - Monday, 07 May 2012, 23:25 GMT
Could you possibly have initscripts in IgnorePkg= in /etc/pacman.conf? That's the only thing I can think of.

Can you confirm that 2012.05.1 fixes the issue?