>>>>> "borsenkow" == Borsenkow Andrej <Andrej.Borsenkow@xxxxxxxxxxxxxx> writes:
>>
>> /dev/log is saved in /lib/dev-state first time after clean start and
>> restored upon starting devfsd. It means, /dev/log exists *immediately*
>> and devfsd tries to do openlog() before real syslog is started early
borsenkow> in
>> rc.sysinit. When syslog is started it tries to remove /dev/log:
>>
>> 2628 unlink("/dev/log") = -1 ENOENT (No such file or
>> directory)
>> 2628 socket(PF_UNIX, SOCK_DGRAM, 0) = 0
>> 2628 bind(0, {sin_family=AF_UNIX, path="/dev/log"}, 10) = 0
>> 2628 chmod("/dev/log", 0666) = 0
>>
>> Any chance of deadlock here? Openlog does connect and send:
>>
>> 2678 connect(1, {sin_family=AF_UNIX, path="/dev/log"}, 16) = 0
>> 2678 send(1, "<13>Feb 14 17:26:06 bor: test", 29, 0) = 29
>> 2678 rt_sigaction(SIGPIPE, {SIG_DFL}, NULL, 8) = 0
>> 2678 close(1) = 0
>>
>> which means /dev/log is not empty (whatever it means) when syslog
borsenkow> tries
>> to remove it because nobody was there to consume message yet?
>>
borsenkow> Getting these straces I killed syslog and restarted it. As a result I
borsenkow> could not login anymore, all attempts just hung after accepting
borsenkow> password. Unfortunately, SysRq-T responded only with "show tasks"
borsenkow> explanation, but it did exactly that when system hung on startup.
borsenkow> So it is very possibly related to /dev/log being created too early.
Of
borsenkow> course system should not deadlock which means some kernel problem. It
borsenkow> may be possible to reproduce it this way - killing and restarting
syslog
borsenkow> and waiting for some time (assuming some activity with /dev/log).
Problem is in devfs :((( But I completeely failed to explain it to
Richard how devfsd protocol broke when there are two programs
removing/creating /dev/log.
Later, Juan.
--
In theory, practice and theory are the same, but in practice they
are different -- Larry McVoy
|