5 ms·

"Modern daemons should follow a SIMPLER yet more powerful scheme" LOL. I don't mind systemd in turnkey consumer products like chromebooks or in enterprise. Mayb

"Modern daemons should follow a SIMPLER yet more powerful scheme" LOL. I don't mind systemd in turnkey consumer products like chromebooks or in enterprise. Maybe it's faster or complexity is necessary to do complex/failsafe things etc. But for me the point of Linux is being able to understand and customize how everything works. Which is not necessarily purely education and impractical. Maybe I have something tangibly useful to myself hooked up to Raspberry Pi GPIO pins and want to control it with a little custom daemon. A shell script with start and stop commands is all the time I have to spare rather than learning all the red tape that may be appropriate for complex software.

userbinator 4y ago
At this point it feels that systemd has also grown its group of fans that try to silence any opposition, and the colour of your post is surely evidence.
- thejosh 4y ago
  I think it's more the inflammatory comments that systemd seems to bring.
amluto 4y ago
> But for me the point of Linux is being able to understand and customize how everything works. I have always thought that is a valuable feature of a Linux system, too. That being said, I’ve also contemplated init scripts and wondered how that could possibly work. And, as anyone who has troubleshooted a stale daemon subprocess, a malfunctioning pidfile, or a messed up rc symlink can attest, legacy init scripts do not actually function very well. Systemd may be far from perfect, but it’s a vast improvement over initscripts.
- rascul 4y ago
  > legacy init scripts do not actually function very well. They function as well as they're written. Some people just shouldn't be writing shell scripts that other people use at their current level.
  - theamk 4y ago
    How about apache authors? The problem of runaway CGI sub-processes is one of my favorite examples of traditional init scripts falling short.
    - rascul 4y ago
      Is that an issue with the init script or with Apache?
  - Spivak 4y ago
    That’s kinda the point, just run your process with no regard to daemonizing, write to stdout, stderr, crash normally with panics, don’t bother forking, don’t clean up fds, don’t think at all about privs, what’s a pid file?, what’s /dev/log?, what’s a scheduler?, and let systemd do all of this correctly for all services regardless of how well written they are.
  - none_to_remain 4y ago
    Some times I have looked at what it takes to write an actually somewhat portable shell script and I decided was one of those people Luckily I've never been called upon to write a shell script that went beyond "works on the bash we have"
- cat_plus_plus 4y ago
  I troubleshoot these things by rebooting my Raspberry Pi, you do something different on your personal devices?
- deleted 4y ago
  [deleted]
- ilyt 4y ago
  We literally removed ~10k lines of code that was just dealing with sysv init scripts bugs when moving to systemd. I have few issues with systemd but benefits far outweight the cons
raggi 4y ago
/etc/systemd/system/foo.service: [Unit] Description=Foo [Service] ExecStart=/usr/sbin/foo-daemon —— Start/stop: systemctl start foo systemctl stop foo On boot: systemctl enable —now foo — Hopefully this helps you skip the red tape.
- cat_plus_plus 4y ago
  My foo-daemon needs some arguments and several steps to shutdown while saving its work. Like maybe kill -HUP, wait 10 seconds and then kill -9. Any suggestions that would be obvious to me without always having you for one-on-one consultation? Rare cases where saving work is not complete after 10 seconds are acceptable for my use case.
  - raggi 4y ago
    Sure, here's the doc this is taken from: https://www.freedesktop.org/software/systemd/man/systemd.service.html#id-1.10.2 https://www.freedesktop.org/software/systemd/man/systemd.ser... You can find this doc by typing "systemd.service" into your favorite search engine. The title I link to is the simple case example, which explains just below the content sample that it has pretty much the behavior you want: Since no ExecStop= was specified, systemd will send SIGTERM to all processes started from this service, and after a timeout also SIGKILL. This behavior can be modified, see systemd.kill(5) for details. Per this, you can either implement SIGTERM rather than SIGHUP, or you can change the stop signal. It already has a generous shutdown timeout (on one of my systems where I have a similarly simple unit, it's defaulted to 1m30s). You can change the timeout by setting https://www.freedesktop.org/software/systemd/man/systemd.service.html#TimeoutStopSec= https://www.freedesktop.org/software/systemd/man/systemd.ser... The docs are pretty good, and worth a scan. Edit: I forgot about the arguments, you can just add them to the ExecStart= line (doc: https://www.freedesktop.org/software/systemd/man/systemd.service.html#ExecStart= https://www.freedesktop.org/software/systemd/man/systemd.ser...).
  - andrewstuart 4y ago
    That's bread and butter work for systemd - exactly what it is designed to handle.

userbinator 4y ago

At this point it feels that systemd has also grown its group of fans that try to silence any opposition, and the colour of your post is surely evidence.

thejosh 4y ago
I think it's more the inflammatory comments that systemd seems to bring.

amluto 4y ago

> But for me the point of Linux is being able to understand and customize how everything works. I have always thought that is a valuable feature of a Linux system, too. That being said, I’ve also contemplated init scripts and wondered how that could possibly work. And, as anyone who has troubleshooted a stale daemon subprocess, a malfunctioning pidfile, or a messed up rc symlink can attest, legacy init scripts do not actually function very well. Systemd may be far from perfect, but it’s a vast improvement over initscripts.

rascul 4y ago
> legacy init scripts do not actually function very well. They function as well as they're written. Some people just shouldn't be writing shell scripts that other people use at their current level.
- theamk 4y ago
  How about apache authors? The problem of runaway CGI sub-processes is one of my favorite examples of traditional init scripts falling short.
  - rascul 4y ago
    Is that an issue with the init script or with Apache?
- Spivak 4y ago
  That’s kinda the point, just run your process with no regard to daemonizing, write to stdout, stderr, crash normally with panics, don’t bother forking, don’t clean up fds, don’t think at all about privs, what’s a pid file?, what’s /dev/log?, what’s a scheduler?, and let systemd do all of this correctly for all services regardless of how well written they are.
- none_to_remain 4y ago
  Some times I have looked at what it takes to write an actually somewhat portable shell script and I decided was one of those people Luckily I've never been called upon to write a shell script that went beyond "works on the bash we have"
cat_plus_plus 4y ago
I troubleshoot these things by rebooting my Raspberry Pi, you do something different on your personal devices?
deleted 4y ago
[deleted]
ilyt 4y ago
We literally removed ~10k lines of code that was just dealing with sysv init scripts bugs when moving to systemd. I have few issues with systemd but benefits far outweight the cons

raggi 4y ago

/etc/systemd/system/foo.service: [Unit] Description=Foo [Service] ExecStart=/usr/sbin/foo-daemon —— Start/stop: systemctl start foo systemctl stop foo On boot: systemctl enable —now foo — Hopefully this helps you skip the red tape.

cat_plus_plus 4y ago
My foo-daemon needs some arguments and several steps to shutdown while saving its work. Like maybe kill -HUP, wait 10 seconds and then kill -9. Any suggestions that would be obvious to me without always having you for one-on-one consultation? Rare cases where saving work is not complete after 10 seconds are acceptable for my use case.
- raggi 4y ago
  Sure, here's the doc this is taken from: https://www.freedesktop.org/software/systemd/man/systemd.service.html#id-1.10.2 https://www.freedesktop.org/software/systemd/man/systemd.ser... You can find this doc by typing "systemd.service" into your favorite search engine. The title I link to is the simple case example, which explains just below the content sample that it has pretty much the behavior you want: Since no ExecStop= was specified, systemd will send SIGTERM to all processes started from this service, and after a timeout also SIGKILL. This behavior can be modified, see systemd.kill(5) for details. Per this, you can either implement SIGTERM rather than SIGHUP, or you can change the stop signal. It already has a generous shutdown timeout (on one of my systems where I have a similarly simple unit, it's defaulted to 1m30s). You can change the timeout by setting https://www.freedesktop.org/software/systemd/man/systemd.service.html#TimeoutStopSec= https://www.freedesktop.org/software/systemd/man/systemd.ser... The docs are pretty good, and worth a scan. Edit: I forgot about the arguments, you can just add them to the ExecStart= line (doc: https://www.freedesktop.org/software/systemd/man/systemd.service.html#ExecStart= https://www.freedesktop.org/software/systemd/man/systemd.ser...).
- andrewstuart 4y ago
  That's bread and butter work for systemd - exactly what it is designed to handle.