Going back to an earlier thread:
Russell Coker writes:
> Firstly I just noticed that devfsd is not calling setsid() after doing
> close(0);close(1);close(2); is there a good reason for this or is it an
> oversight? It is my understanding that all daemons should call setsid()...
>
> I came across this while investigating a problem that occurs with the latest
> sysvinit package in Debian. Sysvinit now makes /dev/console the controlling
> terminal for daemons started before multi-user mode is initiated. This means
> that it will be sent a SIGHUP by the kernel when the session ends (IE
> multi-user mode is started).
>
> The SIGHUP results in the configuration reload which displays annoying error
> messages to the console.
>
> With the current way devfsd works the console is kept open until /dev/log is
> created, at which time openlog() is called and the stdin/stdout/stderr are
> closed.
>
> But the session is ended before syslogd is started.
>
> What can we do about this? Would it be a good idea to do
> close(0);close(1);close(2); at the start of the program and then
> open("/dev/console", O_WRONLY|O_NOCTTY); ?
>
> Of course if you want to start devfsd on some other device and have
> all the error messages go there before syslogd is started and not
> have the messages go there then this won't be what you want.
And I responded:
Why not just call setsid(2) after closing fds[0:2]? I've just added
that to me tree. That avoids the problem you describe above with
having the output go elsewhere and then being redirected to
/dev/console.
Well, now I have another suggestion: call setsid(2) as soon as calling
fork(2), rather than wait until closure of fds[0:2]. This would
prevent hangups from the console reaching devfsd even before it calls
openlog(3). It won't prevent console output prior to openlog(3) being
called, however.
Anyone see any reason not to call setsid(2) early? I'm making this
change, so speak up...
Regards,
Richard....
Permanent: rgooch@xxxxxxxxxxxxx
Current: rgooch@xxxxxxxxxxxxxxx
|