Borsenkow Andrej 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
> 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
> tries
> > to remove it because nobody was there to consume message yet?
>
> Getting these straces I killed syslog and restarted it. As a result I
> could not login anymore, all attempts just hung after accepting
> password. Unfortunately, SysRq-T responded only with "show tasks"
> explanation, but it did exactly that when system hung on startup.
>
> So it is very possibly related to /dev/log being created too
> early. Of course system should not deadlock which means some kernel
> problem. It may be possible to reproduce it this way - killing and
> restarting syslog and waiting for some time (assuming some activity
> with /dev/log).
Agreed, the system shouldn't deadlock. And creating /dev/log early
shouldn't matter either, since if devfsd restores /dev/log, then devfs
won't be sending a CREATE event anyway, so that won't cause devfsd to
open the syslog.
Also, even if devfsd does try to open the syslog, if there isn't a
syslogd running to listen to connections on /dev/log, then openlog(3)
should fail and return immediately. At least, that's what I'd expect.
Someone want to confirm this? Perhaps a good starting point would be
to hack the devfsd code to print diagnostic messages when calling
openlog(3) (before and after) to make sure that openlog(3) isn't
hanging somehow.
If openlog(3) *is* hanging, then I'd like to understand *why*.
Regards,
Richard....
Permanent: rgooch@xxxxxxxxxxxxx
Current: rgooch@xxxxxxxxxxxxxxx
|