undefined | Better HN

0 pointswruza5y ago0 comments

Why do you stumble up on holes, when all you need to know to make a daemon is described in APUE in detail and in hundreds of books and articles? Making a daemon, either via systemd or a classical way, is learning something new.

"We need a process without a process group, session, controlling terminal and mount point. How to do that? Well, fork two times, setsid, chdir, close all descriptors. Let's call that daemon for short."

If one does not understand what all of this really means, or why all of this is part of a question, who do they blame against learning something new?

0 comments

5 comments · 2 top-level

tsimionescu5y ago· 2 in thread

Forking however many times you want is not going to guarantee that your are spawning a daemon. The process will end up being owned by its nearest sub-reaper, which could in theory still be owned by the initial session.

wruzaOP5y ago

That implies that daemons always start from a login session and under a process which does this specific trick. That's not true, unless you explicitly wanted them to malfunction.

tsimionescu5y ago

My point was not that this happens often, but that it is not guaranteed to work (whereas adding your daemon as a systemd service unit is, on systems using systemd).

Also, if you're not starting from a login session, do you really need to double fork?

Joker_vD5y ago· 1 in thread

And why, pray tell, must this logic be duplicated (poorly) in every single "service" application? Isn't the UNIX way "do one thing, and do it well"? Isn't the whole "I, the author of the application, will forcefully disregard the environment the user provided to it" against the UNIX spirit of composability? No UNIX application that I know of re-opens the controlling tty as its stdout — that breaks pipes, so is heavily discouraged and nobody does that. Well, "daemonizing" breaks job control/child process control/service managers, and yet people insist on doing it.

wruzaOP5y ago

Not everyone insists on daemonizing, and not everyone nails their services to whatever popular environment there is. Make it a standard then complain. My point is that doing that also is "learning something new", as opposed to "being a luddite disrespecting our systemd". I'm using systemd and other service managers on all linux instances that I have and with all self-written services, btw, it's just this cool kid stance that bothers.

Also I just downloaded the recent sources of sshd and it does daemon(0, 0) under the hood, unless -D is passed. ssh.service just runs it with -D, so what's the deal? Does one function call for the case when systemd is not there break some religion?

https://github.com/openssh/openssh-portable/blob/V_8_3/sshd....

j / k navigate · click thread line to collapse

0 comments

5 comments · 2 top-level

tsimionescu5y ago· 2 in thread

wruzaOP5y ago

That implies that daemons always start from a login session and under a process which does this specific trick. That's not true, unless you explicitly wanted them to malfunction.

tsimionescu5y ago

My point was not that this happens often, but that it is not guaranteed to work (whereas adding your daemon as a systemd service unit is, on systems using systemd).

Also, if you're not starting from a login session, do you really need to double fork?

Joker_vD5y ago· 1 in thread

wruzaOP5y ago

https://github.com/openssh/openssh-portable/blob/V_8_3/sshd....

j / k navigate · click thread line to collapse