5 ms·

1. You don't have to clone then modify a 100 line bash script for a normal daemon's /etc/rc.d/init.d script.

by ape4 5y ago

fiddlerwoaroof 5y ago
Instead you have to write a couple-hundred-line bash script and then modify an under-documented ini-file to reference it
- merb 5y ago
  you never used systemd?
  - tgv 5y ago
    There's a bit of truth in that. The file format is underdocumented. You've got to look everywhere to find snippets of information, and then there are these weird incompatibilities between versions (Service.Type bit me once, and either After or Wants simply didn't do what the scant information suggested). And it often starts a script or a dedicated tool, e.g. for backing up, or watching directories. However, it's easier to deploy and keep track of your own services, sudo and chdir are built in, there's a watch dog, easy journaling. That's nothing to sneeze at.
    - fiddlerwoaroof 5y ago
      I’ve written a handful of systemd units now and, while the simple cases are nice, anything more complicated is really hard to figure out by reading manpages or other official sources of documentation. And, additionally, I’ve found it’s often easier to write a shell script to be invoked by systemd than to handle certain issues in the unit file itself. As far as the watchdog but things go there’s plenty of good enough solutions that don’t really on systemd: daemonize, DJB’s daemontools, etc.
      - thayne 5y ago
        I've written many systemd services, and other units. Some of which were quite complicated. I found the man pages extremely useful. Moreso than the manpages for sysvinit or upstart, when I used those systems.
      - kaba0 5y ago
        > I’ve found it’s often easier to write a shell script to be invoked by systemd than to handle certain issues in the unit file itself. But that’s a completely fine solution, service files are not meant for declaring arbitrary logic.
jude- 5y ago
The OpenBSD init system and OpenRC init system haven't had this problem for years -- even before systemd became a thing.
- CameronNemo 5y ago
  Similarly runit, s6, and Upstart have never had that issue. It is the oddest complaint to come up with when considering life without systemd.
  - jraph 5y ago
    Upstart was good and probably paved the way to systemd.
    - agumonkey 5y ago
      I wonder if systemd is influencing a new init right now
    - cbmuser 5y ago
      No, Upstart’s design was so bad that even Scott James Remnant (the creator of Upstart) admitted it’s design was inherently flawed. The biggest problem with Upstart was that it put the dependency chain upside down and just started a service whenever it’s dependencies were fulfilled, no matter whether it actually made sense to start the service.
      - ahartmetz 5y ago
        I remember reading about it and thought it seemed wrong, but presumably the author did his research and knew what he was doing. Oh well. His attitude and the readability of Upstart code were very good, though. The Upstart design was probably easier to implement. With the systemd design, the dependency tree needs to be traversed bottom up (figure out what needs to be started to start the targeted set of services), then top down (start dependees when dependencies are ready). With Upstart, top down was enough. Or so it seems.
      - 5y ago
deleted 5y ago
[deleted]
iso1210 5y ago
I have 90 scripts in my /etc/init.d directory. 51 are less than 100 lines, the most recent one I created is actually a perl script which is 29 lines long.
- fiddlerwoaroof 5y ago
  Yeah, with the #!-lines, sysv init scripts can be written in just about anything and, as long as you implement the expected command line interface, the init system will handle it correctly.
  - MarkSweep 5y ago
    Hmmm, I wonder if anyone has made program for this purpose that will read the rest of the file a declarative definition of a service? Like imagine a SYSTEMd unit file with a shebang at the top .
Arch-TK 5y ago
I've not seen even sysvinit based systems with this problem. Every service manager I know of solves this problem. This is as much an argument in favour of systemd as "don't have to clean up horse excrement" is an argument in favour of owning a fiat 500.
- viraptor 5y ago
  Most init scripts are in that ballpark. See openssh for example (88 lines) https://github.com/openssh/openssh-portable/blob/master/opensshd.init.in https://github.com/openssh/openssh-portable/blob/master/open... And yet, it still tries to use pidfiles (which systemd has a better alternative for), and notes "We really should check if the service is already going" which they don't do because it's an actual non-trivial issue if you're writing a standalone init script.
  - Arch-TK 5y ago
    Does anyone use these init scripts? Every popular sysvinit based init system uses short declarative service scripts for most services. Every non-sysvinit init system seems to mostly manage with 2 line scripts. And yes pidfiles are crap and I don't like them either (a genuine criticism of sysvinit and advantage of systemd) but systemd isn't the first init system to do away with pidfiles so it's hardly a unique strength.
    - viraptor 5y ago
      Could you show an example of a declarative sysv-init script? To be honest, I'm not aware of it being possible and ddg doesn't bring up anything. > Does anyone use these init scripts? By default every popular distro before systemd/upstart did. Many services still use them anyways (systemd just generates a shim to run the start/stop/status operations on them)
      - Arch-TK 5y ago
        This is OpenBSD's sshd init script: https://github.com/openbsd/src/blob/master/etc/rc.d/sshd https://github.com/openbsd/src/blob/master/etc/rc.d/sshd On an archlinux system running systemd I see that the equivalent of the rc_reload function is "ExecReload=/bin/kill -HUP $MAINPID" (which is actually less safe...) I'm not sure if you think that's declarative but to me it's basically as declarative as you can make a shell script. > By default every popular distro before systemd/upstart did. Many services still use them anyways (systemd just generates a shim to run the start/stop/status operations on them) I mean is anyone CURRENTLY using them? Because as far as I'm aware the linux sysvinit situation was a gigantic mess which nobody wanted to bother fixing despite the fact that OpenBSD and other BSDs had already fixed it by that point. I think most linux distros can be taken as an example of how not to do things if you want to make your life easier. Nowadays BSDs don't use these awful scripts. OpenRC based systems don't use these awful scripts. Who is using them?

1. You don't have to clone then modify a 100 line bash script for a normal daemon's /etc/rc.d/init.d script.

by ape4 5y ago

1. You don't have to clone then modify a 100 line bash script for a normal daemon's /etc/rc.d/init.d script.

Instead you have to write a couple-hundred-line bash script and then modify an under-documented ini-file to reference it

merb 5y ago
you never used systemd?
- tgv 5y ago
  There's a bit of truth in that. The file format is underdocumented. You've got to look everywhere to find snippets of information, and then there are these weird incompatibilities between versions (Service.Type bit me once, and either After or Wants simply didn't do what the scant information suggested). And it often starts a script or a dedicated tool, e.g. for backing up, or watching directories. However, it's easier to deploy and keep track of your own services, sudo and chdir are built in, there's a watch dog, easy journaling. That's nothing to sneeze at.
  - fiddlerwoaroof 5y ago
    I’ve written a handful of systemd units now and, while the simple cases are nice, anything more complicated is really hard to figure out by reading manpages or other official sources of documentation. And, additionally, I’ve found it’s often easier to write a shell script to be invoked by systemd than to handle certain issues in the unit file itself. As far as the watchdog but things go there’s plenty of good enough solutions that don’t really on systemd: daemonize, DJB’s daemontools, etc.
    - thayne 5y ago
      I've written many systemd services, and other units. Some of which were quite complicated. I found the man pages extremely useful. Moreso than the manpages for sysvinit or upstart, when I used those systems.
    - kaba0 5y ago
      > I’ve found it’s often easier to write a shell script to be invoked by systemd than to handle certain issues in the unit file itself. But that’s a completely fine solution, service files are not meant for declaring arbitrary logic.

jude- 5y ago

The OpenBSD init system and OpenRC init system haven't had this problem for years -- even before systemd became a thing.

CameronNemo 5y ago
Similarly runit, s6, and Upstart have never had that issue. It is the oddest complaint to come up with when considering life without systemd.
- jraph 5y ago
  Upstart was good and probably paved the way to systemd.
  - agumonkey 5y ago
    I wonder if systemd is influencing a new init right now
  - cbmuser 5y ago
    No, Upstart’s design was so bad that even Scott James Remnant (the creator of Upstart) admitted it’s design was inherently flawed. The biggest problem with Upstart was that it put the dependency chain upside down and just started a service whenever it’s dependencies were fulfilled, no matter whether it actually made sense to start the service.
    - ahartmetz 5y ago
      I remember reading about it and thought it seemed wrong, but presumably the author did his research and knew what he was doing. Oh well. His attitude and the readability of Upstart code were very good, though. The Upstart design was probably easier to implement. With the systemd design, the dependency tree needs to be traversed bottom up (figure out what needs to be started to start the targeted set of services), then top down (start dependees when dependencies are ready). With Upstart, top down was enough. Or so it seems.
    - 5y ago

deleted 5y ago

[deleted]

iso1210 5y ago

I have 90 scripts in my /etc/init.d directory. 51 are less than 100 lines, the most recent one I created is actually a perl script which is 29 lines long.

fiddlerwoaroof 5y ago
Yeah, with the #!-lines, sysv init scripts can be written in just about anything and, as long as you implement the expected command line interface, the init system will handle it correctly.
- MarkSweep 5y ago
  Hmmm, I wonder if anyone has made program for this purpose that will read the rest of the file a declarative definition of a service? Like imagine a SYSTEMd unit file with a shebang at the top .

Arch-TK 5y ago

I've not seen even sysvinit based systems with this problem. Every service manager I know of solves this problem. This is as much an argument in favour of systemd as "don't have to clean up horse excrement" is an argument in favour of owning a fiat 500.

viraptor 5y ago
Most init scripts are in that ballpark. See openssh for example (88 lines) https://github.com/openssh/openssh-portable/blob/master/opensshd.init.in https://github.com/openssh/openssh-portable/blob/master/open... And yet, it still tries to use pidfiles (which systemd has a better alternative for), and notes "We really should check if the service is already going" which they don't do because it's an actual non-trivial issue if you're writing a standalone init script.
- Arch-TK 5y ago
  Does anyone use these init scripts? Every popular sysvinit based init system uses short declarative service scripts for most services. Every non-sysvinit init system seems to mostly manage with 2 line scripts. And yes pidfiles are crap and I don't like them either (a genuine criticism of sysvinit and advantage of systemd) but systemd isn't the first init system to do away with pidfiles so it's hardly a unique strength.
  - viraptor 5y ago
    Could you show an example of a declarative sysv-init script? To be honest, I'm not aware of it being possible and ddg doesn't bring up anything. > Does anyone use these init scripts? By default every popular distro before systemd/upstart did. Many services still use them anyways (systemd just generates a shim to run the start/stop/status operations on them)
    - Arch-TK 5y ago
      This is OpenBSD's sshd init script: https://github.com/openbsd/src/blob/master/etc/rc.d/sshd https://github.com/openbsd/src/blob/master/etc/rc.d/sshd On an archlinux system running systemd I see that the equivalent of the rc_reload function is "ExecReload=/bin/kill -HUP $MAINPID" (which is actually less safe...) I'm not sure if you think that's declarative but to me it's basically as declarative as you can make a shell script. > By default every popular distro before systemd/upstart did. Many services still use them anyways (systemd just generates a shim to run the start/stop/status operations on them) I mean is anyone CURRENTLY using them? Because as far as I'm aware the linux sysvinit situation was a gigantic mess which nobody wanted to bother fixing despite the fact that OpenBSD and other BSDs had already fixed it by that point. I think most linux distros can be taken as an example of how not to do things if you want to make your life easier. Nowadays BSDs don't use these awful scripts. OpenRC based systems don't use these awful scripts. Who is using them?