Steve Litt - 15.05.24, 08:15:03 CEST:
> >I'd not consider something like
> >
> >#!/bin/sh
> ># kFreeBSD do not accept scripts as interpreters, using #!/bin/sh and
> >sourcing. if [ true != "$INIT_D_SCRIPT_SOURCED" ] ; then
> >
> > set "$0" "$@"; INIT_D_SCRIPT_SOURCED=true . /lib/init/init-d-script
[…]
> >particularly huge.
>
> I wouldn't either, always assuming that init-d-script is reasonably
> sized and readable with minimal source imports of its own.
>
> It's too bad you (Martin) didn't write all the other init scripts, some
> of which clock in at over 200 lines of hairy shellscripting code.

It was not really my idea.

I took the inspiration from some other init script and the man page
documentation for init-d-script. Yes, it does have a man page which
explains the logic. And for special cases you could override an action
like "start" or "stop".

One of the arguments for Systemd was avoiding code duplication, writing
the same thing over and over again. But init-d-script, start-stop-daemon
and other tools allowed to reduce code duplication for SysVInit as well.

Similar to that Runit comes with some tools like "chpst" and Lozenzo's
package runit-services standardizes quite a bit and reduces code
duplication for example for starting logging services as well. And it
would be easy enough I bet to either extend "chpst" or preferably do
another little tool to setup a control group for a process and optionally
configure some control group limits for it. Or put a process into a name
space and what not. One can argue that a one time setup for a control
group may not be flexible enough and one would need a daemon to handle run
time changes, but for the usual cases is that really the case? Also runsv
can restart a process in case it goes away without even requiring a
control group. Thus it would be easy enough to let a tool to setup a
control group be a no-op on other operating systems like Linux or even
just call that tool in case the OS is Linux.

Even after all the years I see no need to make a System service manager
depend on Linux only features like System does. I am not convinced that
any benefits would outweigh loosing portability.

Also with a run script I could basically do anything I want without
needing it to be implemented in Runit first. Yes, you can do that with
Systemd as well. You can still easily enough call a shell script there.
And haha, I have seen that. Cases where Systemd was just used to start a
shell script to start the service. And I thought: What is even the point
of it? Why would I use over 1 MiB binary – yes, newer versions of Systemd
are smaller, but when you add libsystemd to it, you are way over 1 MiB –
when a combination of three about 30 KiB binaries with minimal
dependencies can do the job (runit, runsv, runsvdir)? I am still not
getting it.

--
Martin