Bugzilla – Bug 158734
preload hangs blocking on xdmctrl socket
Last modified: 2006-06-13 11:27:20 UTC
Investigating why a particular machine refused to boot (boot just stopped), i found out the following (going from init 1 to init 3, then to init 5, suddenly it hung): root 3500 0.0 0.1 7976 1548 ? Ss 18:45 0:00 /bin/bash /etc/init.d/rc 5 root 3520 0.0 0.0 2644 688 ? S 18:45 0:00 \_ startpar -p4 -t 30 -T 3 -M start -P 3 -R 5 root 3558 0.0 0.1 7972 1544 ? S 18:45 0:00 \_ /bin/sh /etc/init.d/earlykdm start root 3564 0.0 0.0 2604 420 ? S 18:45 0:00 \_ /sbin/preload /etc/preload.d/kdm.auto so i straced pid 3564 and found it hanging in: open("/var/run/xdmctl/xdmctl", O_RDONLY <unfinished ...> forever. Once i killed 3564, the machine continued booting. tux@e73:~> grep xdmctl /etc/preload.d/* /etc/preload.d/kdm:open /var/run/xdmctl/xdmctl /etc/preload.d/kdm:open /var/run/xdmctl/xdmctl-:0 /etc/preload.d/kdm.auto:open /var/run/xdmctl/xdmctl /etc/preload.d/kdm.auto:open /var/run/xdmctl/xdmctl-:0 First, the pipes should not be in the preload files at all. Removing them is a fragile solution, however, so the real solution IMO would be to check in preload if the file to be preloaded is a regular file and just skip it otherwise.
Hmm, that's a bug in the code path I don't understand. Normally this very line should avoid your problem (I removed the xdmctl, but it should be a problem on all machines): if (!S_ISREG(buf.st_mode)) goto out; Where is that machine btw?
Joe's laptop. You can have it on Monday if you want. I need it for work tomorrow and over the weekend.
note that i moved the preload.d/kdm* to preload.d/removed/* so the machine would boot at all. I think it is some strange race condition that hits here.
The problem is, that preload does check the regularity of a file before actually reading it. But it does so after opening it (otherwise two directory lookups would be needed). The problem with these bloody pipes is that the open hangs already. Pipes normally shouldn't be in the input lists to preload, and in fact are removed by prepare_preload, when transforming the files in /etc/preload.d/ to the cached layouted variants in /var/cache/preload/ . Problem is when this cache doesn't yet exist or is outdated. In that case the new preload will use the lists from /etc/preload.d/ directly, and run into this problem. I've fixed this in the one which I'll submit shortly.
i did not see this in 10.1 final