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.
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)
> 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)
Honestly I wouldn't be surprised if much of the negativity surrounding systemd (other than people who don't like the architectural approach) is from not being able to use a clean startup configuration, instead having to use a bolted-together compilation of startup methods under the systemd "brand".
It's been a while since I've confirmed this with a new install, but while my Arch Linux setup is very clean, Ubuntu has always been a mess. It still has compatibility with the old "service" command (from Upstart I think?) for goodness sake. My Ubuntu install still has a ton of scripts running under the systemd shim, while as far as I can tell everything that is running on Arch has a .service file. If you're going to appreciate the value of systemd, the latter is a much better experience.
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?
It's highly abstracted with macros, but that's not the same as declarative. It's still using full shell evaluation and any service can complicate it or make it slightly different. It's pretty close though.
> I see that the equivalent of the rc_reload function is "ExecReload=/bin/kill -HUP $MAINPID" (which is actually less safe...)
> man: "rc_reload - Send a SIGHUP signal using pkill(1) on the regular expression given in the pexp variable."
I don't understand why it would be less safe. $MAINPID is well defined because systemd knows the top process in that service's group. A pkill/regex by definition matches by text, so it can HUP any process with matching name - whether it was started by this service or not.
> I mean is anyone CURRENTLY using them?
Not that I'm aware of. They're still installed for people who don't have a different supported init system, but that's just edge cases these days.
It's less safe because it reloads sshd regardless of if the reload would cause sshd to fail to reload. It runs a config check of sshd before it goes ahead and asks sshd to reload its config.
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.