3 ms·

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

by 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
    Systemd is complicated because software that does it all always is. You might not need the features, but someone does, and putting it all in one places means everyone can use the same tool, and nobody has to learn 10 different systems for slightly different tasks.
    - cykros 2y ago
      Software doing it all is antithetical to the Unix philosophy of "Do one thing and do it well." Hence the hate that systemd has, and always will have, as long as there exists a community of people who use Linux because it is a Unix-like operating system. But, Linux is versatile enough that everyone can have their own little fiefdom. The real rage came in years ago when tools that were widely used by all suddenly became reliant upon systemd to function at all. Thankfully, in the time since, enough development has happened that mostly people are free to choose what they do and don't want to run again. The manner in which it was foisted upon the community, however, was one that hopefully will be remembered as being far more aggressive than should be repeated in the future. But, I imagine that as long as Lennart Poettering walks the Earth, we likely will have yet another similarly awful episode.
      - eternityforest 2y ago
        I think a big issue is just that it takes more effort to support multiple init systems. It's hard to be particularly excited about maintaining support for something you don't have a use for yourself, and nobody is paying for(Or at least not as many people in your core audience). Seems like we're in a pretty good place now, with separate development efforts by and for the people who are actually interested in anything but systemd.
deleted 2y ago
[deleted]

by theamk 2y ago

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
  Systemd is complicated because software that does it all always is. You might not need the features, but someone does, and putting it all in one places means everyone can use the same tool, and nobody has to learn 10 different systems for slightly different tasks.
  - cykros 2y ago
    Software doing it all is antithetical to the Unix philosophy of "Do one thing and do it well." Hence the hate that systemd has, and always will have, as long as there exists a community of people who use Linux because it is a Unix-like operating system. But, Linux is versatile enough that everyone can have their own little fiefdom. The real rage came in years ago when tools that were widely used by all suddenly became reliant upon systemd to function at all. Thankfully, in the time since, enough development has happened that mostly people are free to choose what they do and don't want to run again. The manner in which it was foisted upon the community, however, was one that hopefully will be remembered as being far more aggressive than should be repeated in the future. But, I imagine that as long as Lennart Poettering walks the Earth, we likely will have yet another similarly awful episode.
    - eternityforest 2y ago
      I think a big issue is just that it takes more effort to support multiple init systems. It's hard to be particularly excited about maintaining support for something you don't have a use for yourself, and nobody is paying for(Or at least not as many people in your core audience). Seems like we're in a pretty good place now, with separate development efforts by and for the people who are actually interested in anything but systemd.

deleted 2y ago

[deleted]