Re: [LineControl-development] linesrv doesn't close standard file descriptors

[Jonathan R. <jo...@te...>]

Daniel Roethlisberger wrote:
> The second fork seems to have been there for a good reason: some systems
> allegedly require it in order to make sure the daemon process is not
> associated with a TTY. Bottom line: needs some research before removal.

That's really odd if true. I thought that's what setsid() was 
for. According to both my Glibc and the OpenBSD documentation, it 
causes the current process to become the leader of a new session; 
one with no controlling tty.

But, who knows what kinds of aberrant or broken implementations 
there might be out there. I guess it's better to be safe than 
sorry. I've never written a daemon before, though, so all of this 
is new to me. I looked at an example, which could have led me astray:

<URL:http://skywalker.mis.boun.edu.tr/~karakas/daemon.php>

> I have committed a modified and commented version of the patch to CVS
> HEAD in linesrv-2.1. It works for me. I have not touched linesrv-3, as
> the code in question is triplicated (well, duplicated twice, so code is
> in 3 places) and needs to be cleaned up before thinking about doing
> "proper" daemonizing.

Is linesrv-3 usable yet? I looked at the age of the files and 
wondered if it was dead. I wanted to try it before submitting the 
patch, but I wasn't even sure how to build it. Must one invoke 
automake or autoconf to get a configure script?

> 
> It seems that the Really Right Thing to do will be to call the daemon(3)
> syscall on systems where it is available, instead of doing all the
> daemonizing ourselves (and possibly screwing up).

Yes, it looks like daemon() is the ticket. I wasn't even aware of 
it until I read your message. I guess it should come as no 
surprise that such a common activity would be made into a library 
function.

Jonathan Rogers