[HN Gopher] Daemonization in Unix programs is probably about res...
___________________________________________________________________
Daemonization in Unix programs is probably about restarting
programs
Author : ingve
Score : 48 points
Date : 2024-10-07 10:28 UTC (1 days ago)
(HTM) web link (utcc.utoronto.ca)
(TXT) w3m dump (utcc.utoronto.ca)
| sophacles wrote:
| Is there an archive link for this by any chance? I got a 403
| error trying to load it with this message: "You appear to be
| trying to break this web server. Goodbye."
| cpach wrote:
| Yep! You can find copies of the article both on Wayback Machine
| and on archive.ph https://archive.ph/
| cpach wrote:
| I love that Siebenmann is taking the time to document the nitty-
| gritty details of the evolution of Unix. Systems like 4.2BSD are
| long gone from the market, but we still see their influence all
| over the place.
| amelius wrote:
| Daemons suck if you're not in the microservices camp.
| _hyn3 wrote:
| Can you explain further? daemons are OS-level and predate
| microservices by like a half-century, so how are they relevant
| to microservices?
| MathMonkeyMan wrote:
| If you're administering a server, what else is there?
|
| There are service managers like systemd and shepherd, which use
| daemonization under the hood. Then there's container
| orchestration like docker compose, kubernetes, etc. For my toy
| servers at home I just use screen and have it set up
| automatically at boot.
|
| What do you use outside of the microservices camp?
| topspin wrote:
| "these days it's somewhat controversial and sometimes considered
| undesirable"
|
| By whom and for what reason? Every non-trivial OS has some form
| of "daemon" concept, regardless of what name it's given. What
| alternative is proposed? All I get from this statement is
| discussion about the deficiencies of how demonization is
| performed.
|
| [edit] I get it. Don't deamonize yourself. That's fine, and a
| good idea: it's frequently done wrong and even when it's done
| right things change and otherwise correct software is suddenly
| wrong again.
| aeldidi wrote:
| They just mean service managers like SystemD and OpenRC prefer
| to handle daemonizing themselves, and thus would prefer that
| your program stay in the foreground and let them put it in the
| background.
|
| From OpenRC's docs[0]: Daemons must not fork.
| Any daemon that you would like to have monitored by supervise-
| daemon must not fork. Instead, it must stay in the foreground.
| If the daemon forks, the supervisor will be unable to monitor
| it. If the daemon can be configured to not fork,
| this should be done in the daemon's configuration file, or by
| adding a command line option that instructs it not to fork to
| the command_args_foreground variable shown below.
|
| The "undesired" or "controversial" part is whether programs
| should do it themselves or not.
|
| [0]: https://github.com/OpenRC/openrc/blob/master/supervise-
| daemo...
| mrweasel wrote:
| deamontools was the first supervisor service I used that
| required that programs not background themselves, it even
| included a tool for preventing "legacy" daemons from doing
| so.
|
| It made a lot of sense to me at the time and honestly felt
| easier. Going back to init.d or upstart just felt like a step
| backward and so much more complicated that it needed to be.
| Then SystemdD comes along an have the same expectation and
| things makes sense again and writing "startup scripts became
| as easy almost as it was with daemontools.
| wahern wrote:
| inetd, the "super server" from 4.3BSD, supported this in
| addition to handling the listening socket. For reasons I
| don't fully understand, inetd fell out of favor despite
| having been installed and running by default on pretty much
| every *BSD and Linux server for decades.
| hibbelig wrote:
| I recall that inetd started a new instance of the demon
| for every incoming connection, and this caused lots of
| processes when lots of connections happened.
|
| I don't recall whether you could tell inetd not to do
| that.
| wahern wrote:
| inetd could pass the listening socket to the process.
| That was the `wait|nowait` field in /etc/inetd.conf. The
| typical config for TCP used with services like finger was
| `nowait`, which meant inetd would listen on a socket and
| spawn a new process for every incoming connection,
| without waiting for a previously spawned process to exit.
| But in `wait` mode it would spawn the process when it
| detected a connection, pass the listening socket (not
| connected socket) as fd 0, then wait for the server to
| exit before polling the listening socket again.
|
| inetd was (remains?) a perfectly useful solution in this
| space. It just maybe needs some love to add some
| convenience features. Off the top of my head: 1) ability
| to split /etc/inetd.conf into, e.g., /etc/inetd.conf.d;
| 2) ability to trigger a restart of a specific service,
| rather than restarting the entirety of inetd.
| actionfromafar wrote:
| Daemontools is tiny, systemd is huge, but the only thing I
| like about systemd, daemontools could also do.
| masklinn wrote:
| > By whom and for what reason?
|
| By everyone and for the reason that service managers lose track
| of the process, so it increases program complexity for a net
| negative in usability.
|
| > Every non-trivial OS has some form of "daemon" concept,
| regardless of what name it's given.
|
| And none of that is relevant, TFA is about the unix self-
| daemonization pattern, that is what's undesirable.
| JackSlateur wrote:
| If your service manager cannot track forked process, that
| would be quite an issue anyway
|
| "Daemonization" is nothing but fork + exec (and exit from the
| parent)
|
| From the service manager, there should be few distinctions
| between this and, say, pgsql forking to handle connections.
| In both cases, I expect all child processes to be tracked.
|
| And please do not tell me the "health check" part : having
| the main process alive is a broken health check, just like
| having a server powered-on is a far from enough
| kbolino wrote:
| There is one very important distinction.
|
| If pgsql forks to handle connections, the PPID of the child
| processes points back to the "main" pgsql process, which is
| still around.
|
| Whereas, traditionally, if a wannabe daemon forks _and
| exits_ , the PPID of its now orphaned child reverts to 1.
| zokier wrote:
| afaik you need cgroups if you want to accurately track a
| process tree regardless of what silly tricks the
| processes might be try to escape
| gargalatas wrote:
| daemonization is the process of running a process in the
| background and without being attached to a terminal. Many
| applications exit when they are detached from the terminal they
| starter even when they yield no output. Maybe that is why it's
| still there. Of course back in the day fork() was all about
| creating background processes that were running quietly in the
| background were screen didn't exist yet and terminals were actual
| machines, not just one more window. Today System D doesn't like
| daemonization. IT prefers a process that can be attached
| somewhere.
| jeffbee wrote:
| > without being attached to a terminal
|
| Isn't that more the job of `nohup`?
| renewiltord wrote:
| I prefer non-daemon things that I can use systemd to manage with
| Unit files Type=Simple. Very easy, sends things to journal for
| logging. All very nice and clean. Self-daemonization is anti-
| pattern for new software. Non-UNIX DOTW.
| Joel_Mckay wrote:
| "these days it's somewhat controversial and sometimes considered
| undesirable"
|
| I respectfully disagree.
|
| It it fundamentally related to your use-cases, execution times,
| and design paradigms.
|
| If your team comes from a *nix background, than having dozens of
| processes interfacing over various pipes/network-
| sockets/fifo/mem-share is normal. In a cluster environment,
| having the ability to spin up processes on any host, yet remain
| functional over middle-ware can be very robust from a maintenance
| perspective.
|
| A periodic self-restart trigger feature is only a small part of
| these feature sets.
|
| Containerization on the other hand was necessitated out of poor
| OS design consistency, and rotten permission handling. It added
| overhead, complexity, and costs. However, it also solved a very
| real user requirement of keeping many things operational at the
| same time.
|
| Daemons are almost certainly still required if you have software
| that must remain running for >6 months outside a users session.
| Also, periodic processes do not necessarily have to remain
| resident in all use cases if that was a concern.
|
| Best of luck, =3
| zokier wrote:
| practically every system is running service manager of some
| sort (supervisord, daemontools, runit, or infamously systemd
| etc), and with a service manager daemonization is something
| between completely useless and actively harmful. as cks
| explains in the post, daemonization is truly relevant only if
| you are starting your daemons directly somehow somewhere, and
| that went out of fashion somewhere in the turn of the century.
___________________________________________________________________
(page generated 2024-10-08 23:00 UTC)