>>>>> "richard" == Richard Gooch <rgooch@xxxxxxxxxxxxxxx> writes:
richard> Thierry Vignaud writes:
>> Juan Quintela <quintela@xxxxxxxxxxxxxxxx> writes:
>>
>> > > BTW, Juan: I haven't yet received a followup about what was going
>> > > wrong with your /lib/dev-state and /dev/log problems.
>> >
>> > I don't know really, I think that it was a devfsd package here that
>> > got a wrong config file :(
>>
>> the /dev/log problem has been traced back to the following portion of
>> /etc/rc.d/rc.sysinit :
>>
>>
>> # Restart devfsd actions now that the filesystems are ready
>> if [ -c /dev/.devfsd ]; then
>> if [ -x /sbin/devfsd ]; then
>> # cleanup dynamic desktop directories before calling devfsd actions
>> rm -f /usr/share/gnome/desktop/* /usr/share/apps/kdesktop/Desktop/*
>>
>> action "Running devfsd actions: " killall -HUP devfsd
>> fi
>> fi
>>
>>
>> sometimes, the bootstraping process wait for minutes because of some
>> sort of race between devfsd and minilogd (remeber syslogd hasn't yet
>> be started since it's a service launched after rc.sysinit let rc play
>> with init levels.
>>
>> we've found a solution: make a service of the previous piece of script
>> and run it very late (ie in 99th position whereas syslogd service has
>> a priority of 88).
richard> Ug! I hate work-arounds. Can you put time into helping track down
richard> whether there is a bug in devfs or devfsd, and what the cause of the
richard> bug is?
I sent you a kernel trace with the _two_ minilogd & the devfsd trace.
I don't know an easy way to get a gdb trace of devfsd in user space at
this point in the boot procedure.
Basically the problem is (from my reading of the traces):
- one minilogd do:
unlink("/dev/log");
this blocks (kernel space) wating for some kind of devfsd
confirmation.
- other minilogd tries to create /dev/log as an UNIX socket, and it
takes some devfs semafore or similarn.
- devfsd is not able to get that semaphore, which means that the first
minilogd is unable to finish (the unlink of /dev/log), and then
second minilogd is not able either of finish is creation of the UNIX
socket (/dev/log is still not removed).
This was after a fast look at the minilogd source, I still don't know
why minilogd forks itself.
Later, Juan.
--
In theory, practice and theory are the same, but in practice they
are different -- Larry McVoy
|