4 ms·

I was a systemd hater. I agree with a lot of the post but in practice I need a whole lot less custom scripts, forking code, etc to maintain a simple service wh

by taf2 2y ago

I was a systemd hater. I agree with a lot of the post but in practice I need a whole lot less custom scripts, forking code, etc to maintain a simple service whether it’s a custom c binary, go, rust, nodejs , ruby , python… I don’t need to mess with monit(for most things) and yeah in less words then my post here I could have a working service that would both restart on crash and on reboot…. Do I miss the init.d scripts and writing pid files forking twice to change user … no

matheusmoreira 2y ago
> writing pid files forking twice to change user No idea why software tries to "daemonize" anyway. Seems to be some kind of weird tradition. It's always been the wrong thing to do. They should just run normally and output to standard streams even if it's connected to a terminal. The reasons are outlined here: https://mywiki.wooledge.org/ProcessManagement https://mywiki.wooledge.org/ProcessManagement Ironically, systemd is one of few service managers which can properly track those weird "daemonizing" processes. It uses Linux's cgroups. It doesn't matter how many times they fork, they can't hide from systemd.
- theamk 2y ago
  Not sure what exactly you were pointing to, but section "Doing it right" (4.3.1) recommends: mydaemon & daemonpid=$! This is a terrible advice - that's how you end up with all sorts of bad things: - you ssh'd into server, restarted server, checked it worked. Then you logged out and server got killed. - your server runs as root or power user - your server output/error goes somewhere, not clear where - your server's process got paused by SIGTTOU, because it was trying to write to console etc... The complex daemonization dance, with double-forks, closing random FDs, etc.. was required to avoid all this bad stuff before systemd days. Sysvinit/openrc folks came up with "start-stop-daemon" helper, but it was pretty terrible in general, especially in logging department (it had none).
  - matheusmoreira 2y ago
    Handling all of those conditions is the job of a proper service manager like systemd. It does things like restart processes that died, redirect output to logs, set process user and group, etc. The point is software should be written to make the service manager's job as easy as possible by keeping it simple.
    - adrian_b 2y ago
      I agree that handling all those conditions is the job of a proper service manager. I disagree that systemd is a proper service manager. Systemd is horribly complicated in comparison with what is actually needed to implement a proper service manager, as demonstrated e.g. by D. J. Bernstein's daemontools and their many derivatives. Perhaps systemd is better these days, but a few years ago when I have tried systemd on one of my servers I have stumbled upon a bug that could be explained not by some random programmer mistake but only by a bad global architecture of the program. That bug made me mistrust the competence of the systemd creators, so I have never tried to use it again. Moreover, systemd does not provide any feature that I could consider useful and that is not available in alternative service managers, so there were no reasons for further experiments with it. (That systemd bug was a bug that I have never seen in a computer without systemd, from the mainframes of 50 years ago to the latest computers, regardless of the operating system. Due to a race condition in systemd, sometimes the shutdown or reboot of a computer could fail, with the computer remaining stuck in a deadlock, i.e. in an infinite loop, without properly saving all state and closing all resources.)
      - happymellon 2y ago
        Do you have the link to the bug you raised?
      - ksp-atlas 2y ago
        The bug you mentioned is very common, I've experienced it myself and others I know have too
      - eternityforest 2y ago

by taf2 2y ago

matheusmoreira 2y ago

> writing pid files forking twice to change user No idea why software tries to "daemonize" anyway. Seems to be some kind of weird tradition. It's always been the wrong thing to do. They should just run normally and output to standard streams even if it's connected to a terminal. The reasons are outlined here: https://mywiki.wooledge.org/ProcessManagement https://mywiki.wooledge.org/ProcessManagement Ironically, systemd is one of few service managers which can properly track those weird "daemonizing" processes. It uses Linux's cgroups. It doesn't matter how many times they fork, they can't hide from systemd.

theamk 2y ago
Not sure what exactly you were pointing to, but section "Doing it right" (4.3.1) recommends: mydaemon & daemonpid=$! This is a terrible advice - that's how you end up with all sorts of bad things: - you ssh'd into server, restarted server, checked it worked. Then you logged out and server got killed. - your server runs as root or power user - your server output/error goes somewhere, not clear where - your server's process got paused by SIGTTOU, because it was trying to write to console etc... The complex daemonization dance, with double-forks, closing random FDs, etc.. was required to avoid all this bad stuff before systemd days. Sysvinit/openrc folks came up with "start-stop-daemon" helper, but it was pretty terrible in general, especially in logging department (it had none).
- matheusmoreira 2y ago
  Handling all of those conditions is the job of a proper service manager like systemd. It does things like restart processes that died, redirect output to logs, set process user and group, etc. The point is software should be written to make the service manager's job as easy as possible by keeping it simple.
  - adrian_b 2y ago
    I agree that handling all those conditions is the job of a proper service manager. I disagree that systemd is a proper service manager. Systemd is horribly complicated in comparison with what is actually needed to implement a proper service manager, as demonstrated e.g. by D. J. Bernstein's daemontools and their many derivatives. Perhaps systemd is better these days, but a few years ago when I have tried systemd on one of my servers I have stumbled upon a bug that could be explained not by some random programmer mistake but only by a bad global architecture of the program. That bug made me mistrust the competence of the systemd creators, so I have never tried to use it again. Moreover, systemd does not provide any feature that I could consider useful and that is not available in alternative service managers, so there were no reasons for further experiments with it. (That systemd bug was a bug that I have never seen in a computer without systemd, from the mainframes of 50 years ago to the latest computers, regardless of the operating system. Due to a race condition in systemd, sometimes the shutdown or reboot of a computer could fail, with the computer remaining stuck in a deadlock, i.e. in an infinite loop, without properly saving all state and closing all resources.)
    - happymellon 2y ago
      Do you have the link to the bug you raised?
    - ksp-atlas 2y ago
      The bug you mentioned is very common, I've experienced it myself and others I know have too
    - eternityforest 2y ago