8 ms·

With systemd (and afaik other service managers) you don't need/should to do all that daemonization dance. The application can run in the foreground, keep any fd

by zokier 6y ago

With systemd (and afaik other service managers) you don't need/should to do all that daemonization dance. The application can run in the foreground, keep any fds open, don't worry about tty etc because the service manager will take care of them for you. As a cherry on top, anything you write on stdout gets automatically forwarded to journald or wherever. further reading https://www.man7.org/linux/man-pages/man7/daemon.7.html https://www.man7.org/linux/man-pages/man7/daemon.7.html

gilgad13 6y ago
My understanding was that the double fork dance was actively discouraged for any semi-modern system. The man page you link says as much in the "new-style" section, as well as https://jdebp.eu/FGA/unix-daemon-design-mistakes-to-avoid.html https://jdebp.eu/FGA/unix-daemon-design-mistakes-to-avoid.ht.... Just write your server as a straightforward process and let the service manager handle this stuff for you. You'll just be confusing it if you don't.
JdeBP 6y ago
It is rather sad to see something that was out of date in the 1990s still being circulated today. Even the part about process #1 inheriting orphaned processes is 8 or so years out of date. * https://unix.stackexchange.com/a/177361/5132 https://unix.stackexchange.com/a/177361/5132
vimax 6y ago
The more I use systemd the more I love it. It simplifies so much, and adds all the little features I see so many projects using custom implementations for. The people who keep complaining about it seem more and more like children who just refuse to learn something new and better because they've already stumbled through all the holes it fills.
- efiecho 6y ago
  > The people who keep complaining about it seem more and more like children who just refuse to learn something new and better because they've already stumbled through all the holes it fills. Systemd apologists always seems to think that anyone not completely in love with systemd, is just refusing to learn something new. Please stop with the stupidity, people have real reasons to hate that shit. I had no problem with switching to WireGuard, after learning about it, because this is so much better in both use and design than OpenVPN that I have used for 20 years. I had no problem with learning about systemd either, but that is just badly designed software to me.
  - kreetx 6y ago
    For those not in the know, what's wrong with systemd's design?
    - fsflover 6y ago
      There were hundreds of comments about it on HN. One typical complain is it's not implemented according to the Unix philosophy: https://en.wikipedia.org/wiki/Unix_way#Do_One_Thing_and_Do_It_Well https://en.wikipedia.org/wiki/Unix_way#Do_One_Thing_and_Do_I...
      - kreetx 6y ago
        Sure, but that's like saying my coffee machine also makes latte and hot chocolate. I guess what I'm asking is: do any of these taste bad, and how? Perhaps the parent had a few of these on his/her mind that could have been listed.
        fsflover 6y ago
        Unix philosophy has a reason. It allows to easily replace components and simplifies testing. AFAIK it's not easy to replace various parts of systemd, it's very monolithic and it does too many things.
        kreetx 6y ago
        I know the philosophy. What I'm trying to get at is that perhaps the thing that came before was a set of things that didn't quite work together, so now they made something that does. (And was just wondering if there was any specific thing the original parent wanted to replace.)
        fsflover 6y ago
        Some relevant old comments: https://news.ycombinator.com/item?id=12335783 https://news.ycombinator.com/item?id=12335783 https://news.ycombinator.com/item?id=12652071 https://news.ycombinator.com/item?id=12652071 https://news.ycombinator.com/item?id=23065830 https://news.ycombinator.com/item?id=23065830 https://news.ycombinator.com/item?id=8672887 https://news.ycombinator.com/item?id=8672887
- wruza 6y ago
  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?
  - tsimionescu 6y ago
    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.
    - wruza 6y 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.
      - tsimionescu 6y 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_vD 6y ago
    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.
- pydry 6y ago
  I was a fan of upstart. It was simple, it knew how to perform the task it did it, it didn't try to be everything plus the kitchen sink, it worked well and it didn't get its tendrils in everything like systemd does (something that concerns me as it increases the attack surface). It was a technically superior solution murdered by politics. What's worse was all of the people who were going "why are you moaning? what's wrong? systemd is still an improvement on sysvinit!" as if being better than a bunch of bash scripts held together with bits of sticky tape and string was all the qualification needed to be PID 1.
  - teddyh 6y ago
    The creator of systemd argues that the design of upstart was fundamentally flawed: http://0pointer.net/blog/projects/systemd http://0pointer.net/blog/projects/systemd (See heading “On Upstart”)
  - JdeBP 6y ago
    People liked to paint it as politics, but there were technical critiques such as Russ Allbery's for starters. * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#1729 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#172... And yes, people do erroneously paint it as only a choice between van Smoorenburg init+rc and systemd, as if they were the only two possibilities, when in fact in the Debian Hoo-Hah (for one) it was effectively a choice between systemd, upstart, and OpenRC, nearly all parties agreeing at one point in the proceedings that van Smoorenburg init+rc was last choice, either before or after "further discussion". * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#6729 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#672...
    - pydry 6y ago
      The criticisms levied at upstart there are more about lack of features, not really about overall approach. It's easier to add features than it is to fix a deficient design. Moreover, I'm not really so sure a couple of those features even belong in an init system. Debian's decision effectively doomed upstart and led to an init system monoculture. The practical upshot is that no competition for systemd means no pressure to improve. Even for systemd it was a bad decision.
enobrev 6y ago
I've been using systemd to manage daemons but hadn't realized writing to stdout gets forwarded to journald. That's grest to know, thanks.
erik_seaberg 6y ago
Has POSIX ever defined “service manager” as a concept? https://news.ycombinator.com/item?id=11798328 https://news.ycombinator.com/item?id=11798328 points out that glibc’s daemon(3) function isn’t standard but might be a good place to abstract out “do whatever is appropriate for this distro.”
- JdeBP 6y ago
  System administration tooling was famously not addressed by IEEE 1003.1 or 1003.2 originally in the 1980s. It hasn't been addressed since, either. In practice, service managers have been around since 1988. * http://jdebp.uk./FGA/unix-service-access-facility.html http://jdebp.uk./FGA/unix-service-access-facility.html

by zokier 6y ago

gilgad13 6y ago

My understanding was that the double fork dance was actively discouraged for any semi-modern system. The man page you link says as much in the "new-style" section, as well as https://jdebp.eu/FGA/unix-daemon-design-mistakes-to-avoid.html https://jdebp.eu/FGA/unix-daemon-design-mistakes-to-avoid.ht.... Just write your server as a straightforward process and let the service manager handle this stuff for you. You'll just be confusing it if you don't.

JdeBP 6y ago

It is rather sad to see something that was out of date in the 1990s still being circulated today. Even the part about process #1 inheriting orphaned processes is 8 or so years out of date. * https://unix.stackexchange.com/a/177361/5132 https://unix.stackexchange.com/a/177361/5132

vimax 6y ago

The more I use systemd the more I love it. It simplifies so much, and adds all the little features I see so many projects using custom implementations for. The people who keep complaining about it seem more and more like children who just refuse to learn something new and better because they've already stumbled through all the holes it fills.

efiecho 6y ago
> The people who keep complaining about it seem more and more like children who just refuse to learn something new and better because they've already stumbled through all the holes it fills. Systemd apologists always seems to think that anyone not completely in love with systemd, is just refusing to learn something new. Please stop with the stupidity, people have real reasons to hate that shit. I had no problem with switching to WireGuard, after learning about it, because this is so much better in both use and design than OpenVPN that I have used for 20 years. I had no problem with learning about systemd either, but that is just badly designed software to me.
- kreetx 6y ago
  For those not in the know, what's wrong with systemd's design?
  - fsflover 6y ago
    There were hundreds of comments about it on HN. One typical complain is it's not implemented according to the Unix philosophy: https://en.wikipedia.org/wiki/Unix_way#Do_One_Thing_and_Do_It_Well https://en.wikipedia.org/wiki/Unix_way#Do_One_Thing_and_Do_I...
    - kreetx 6y ago
      Sure, but that's like saying my coffee machine also makes latte and hot chocolate. I guess what I'm asking is: do any of these taste bad, and how? Perhaps the parent had a few of these on his/her mind that could have been listed.
      - fsflover 6y ago
        Unix philosophy has a reason. It allows to easily replace components and simplifies testing. AFAIK it's not easy to replace various parts of systemd, it's very monolithic and it does too many things.
        kreetx 6y ago
        I know the philosophy. What I'm trying to get at is that perhaps the thing that came before was a set of things that didn't quite work together, so now they made something that does. (And was just wondering if there was any specific thing the original parent wanted to replace.)
        fsflover 6y ago
        Some relevant old comments: https://news.ycombinator.com/item?id=12335783 https://news.ycombinator.com/item?id=12335783 https://news.ycombinator.com/item?id=12652071 https://news.ycombinator.com/item?id=12652071 https://news.ycombinator.com/item?id=23065830 https://news.ycombinator.com/item?id=23065830 https://news.ycombinator.com/item?id=8672887 https://news.ycombinator.com/item?id=8672887
wruza 6y ago
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?
- tsimionescu 6y ago
  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.
  - wruza 6y 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.
    - tsimionescu 6y 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_vD 6y ago
  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.
pydry 6y ago
I was a fan of upstart. It was simple, it knew how to perform the task it did it, it didn't try to be everything plus the kitchen sink, it worked well and it didn't get its tendrils in everything like systemd does (something that concerns me as it increases the attack surface). It was a technically superior solution murdered by politics. What's worse was all of the people who were going "why are you moaning? what's wrong? systemd is still an improvement on sysvinit!" as if being better than a bunch of bash scripts held together with bits of sticky tape and string was all the qualification needed to be PID 1.
- teddyh 6y ago
  The creator of systemd argues that the design of upstart was fundamentally flawed: http://0pointer.net/blog/projects/systemd http://0pointer.net/blog/projects/systemd (See heading “On Upstart”)
- JdeBP 6y ago
  People liked to paint it as politics, but there were technical critiques such as Russ Allbery's for starters. * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#1729 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#172... And yes, people do erroneously paint it as only a choice between van Smoorenburg init+rc and systemd, as if they were the only two possibilities, when in fact in the Debian Hoo-Hah (for one) it was effectively a choice between systemd, upstart, and OpenRC, nearly all parties agreeing at one point in the proceedings that van Smoorenburg init+rc was last choice, either before or after "further discussion". * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#6729 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#672...
  - pydry 6y ago
    The criticisms levied at upstart there are more about lack of features, not really about overall approach. It's easier to add features than it is to fix a deficient design. Moreover, I'm not really so sure a couple of those features even belong in an init system. Debian's decision effectively doomed upstart and led to an init system monoculture. The practical upshot is that no competition for systemd means no pressure to improve. Even for systemd it was a bad decision.

enobrev 6y ago

I've been using systemd to manage daemons but hadn't realized writing to stdout gets forwarded to journald. That's grest to know, thanks.

erik_seaberg 6y ago

Has POSIX ever defined “service manager” as a concept? https://news.ycombinator.com/item?id=11798328 https://news.ycombinator.com/item?id=11798328 points out that glibc’s daemon(3) function isn’t standard but might be a good place to abstract out “do whatever is appropriate for this distro.”

JdeBP 6y ago
System administration tooling was famously not addressed by IEEE 1003.1 or 1003.2 originally in the 1980s. It hasn't been addressed since, either. In practice, service managers have been around since 1988. * http://jdebp.uk./FGA/unix-service-access-facility.html http://jdebp.uk./FGA/unix-service-access-facility.html