
What 'dependency' means in Unix init systems is underspecified - zdw
https://utcc.utoronto.ca/~cks/space/blog/sysadmin/InitDependencyUnclear
======
tlb
Make lets you specify all 3 kinds of dependencies. _Requirement_ is the
default, _want_ can be had by prefixing the commands with - (ignore errors),
and _ordering_ can be had by putting the prerequisites after a |.

    
    
      foo : requirement want | ordering
    
      requirement:
          generate $@
    
      want:
          - generate $@
    
      ordering:
         generate $@
    

Make could have been the engine behind a lot of unix infrastructure. I suspect
the language-specific stuff like VPATH made it an undesirable choice.

~~~
cperciva
Ordering is a nonportable extension, unfortunately.

~~~
nemoniac
Are there popular non-GNU makes nowadays?

~~~
wongarsu
BSDs usually don't use GNU make by default (though it is usually available as
gmake or similar)

------
userbinator
I wonder if any others here think the whole idea of requiring an "init system"
seems overly complex and almost un-Unix-like for the average use-case of a
personal Linux system, or even a single-purpose server? I've built a minimal
but quite functional system (including networking, a GUI, etc.) with only
"init=/bin/bash" and everything else that needs to be run at startup in
/etc/profile.

In that world, the dependencies are easily expressable in the shell script
itself: requirement is &&, want is ;, and ordering is simply... the order in
which the commands appear in the file. It feels very much in line with the
Unix philosophy. Thus the relative complexity of all the other "init systems",
even including the original sysvinit, seems rather excess to me --- was it
just a case of Linux/Unix originating with multiuser servers and retaining all
of the baggage from that when it became a personal OS?

~~~
akira2501
> and everything else that needs to be run at startup in /etc/profile.

Those are unmanaged services, if they crash for any reason, they won't be
restarted? For embedded use cases this is probably fine, but for desktop it is
a problem.

> In that world, the dependencies are easily expressable in the shell script
> itself [...] It feels very much in line with the Unix philosophy.

This is why I use runit and let the program determine it's own dependencies.
If it fails to start, runit will try again in 1 second... forever. This
actually works great in practice, but it does present a problem for "on-
demand" services.

They can still be built, but I've always avoided them for the problems they
present. For typical 'inetd' applications, I find ucspi-tcp to be an ideal
solution for everything else I try to find some reasonable compromise which
for most of the cases where I need a true managed set of services is very
rare.

> and retaining all of the baggage from that when it became a personal OS?

It's worse in my mind, they're pantomiming the competition which seems to be a
complete misunderstanding of the platform they're using.

~~~
toast0
If you want the service supervised, there's supervisord or daemontools or
while true ; do flakeyserver; done.

On the other hand, some servers are expected to work, and if they crash, it
should be investigated, because it's probably a big deal. In my experience
auto-restart goes hand in hand with never investigate why it restarts.
Sometimes that's appropriate (for software you basically have to run, but
don't control), but more often it's terrible.

~~~
newacctjhro
> If you want the service supervised, there's supervisord or daemontools or
> while true ; do flakeyserver; done.

Or systemd, which is fine for many use cases.

~~~
toast0
1) can you use systemd to supervise a single process without adopting most of
systemd?

2) based on the train of horrors for every single network daemon they write,
do you trust that their systems level code is somehow good?

3) well their record on systems level code isn't that great either, username
parsing really didn't go well

4) is systemd demonstrating engineering excellence of as simple as possible,
but no simpler?

5) out of the box, my experience with Debian + systemd + a crashy service
(from packages) was that the specific crashes I was getting didn't result in a
restart, because it got a segfault instead of simply exiting. --- also, it
changed the boot process so I couldn't ctrl-c out of slow things, so that was
net negative.

------
JdeBP
I saw the original article when it came up at
[https://news.ycombinator.com/item?id=18303019](https://news.ycombinator.com/item?id=18303019)
a couple of days ago. M. Siebenmann is articulating part of one of the points
that I was going to raise.

For what it's worth, the nosh doco does try to articulate the difference
between the dependencies of wants/, conflicts/, et al. and the ordering
relationships of before/ and after/. The former control the extent of the set
of jobs that system-control constructs for an action, whilst the latter
control the order that the jobs in that set are then executed in.

* [http://jdebp.eu./Softwares/nosh/guide/system-control.html](http://jdebp.eu./Softwares/nosh/guide/system-control.html)

------
GlennS
I'm confused.

Systemd has separate 'wants', 'requires', 'after', and 'before', which sounds
like what's being asked for here?

~~~
dralley
If you reread the opening paragraph - the author is responding to part of a
blog post which questioned why a separation between ordering and dependencies
was necessary, and provides an example.

------
Too
While on the topic of underspecified dependencies, another thing usually
missed when writing init dependencies is that it's not enough to just start
the depending service, it also has to perform some actions before the actual
dependency is fulfilled. This can some times take several seconds and many
services don't feedback to the init system when it's done.

With wants dependencies this isn't so critical but if you have requires it
must be factored in.

~~~
bonzini
Which is why systemd discourages daemonizing in the service and introduces
both socket units (so that you can always connect to the server socket, you do
not need to wait for the child to call bind(2)) and a simple notification
protocol.

~~~
cyphar
Socket activation is nice for certain things, like webservers. Unfortunately
for other services socket activation can cause you far more headaches. For
instance, Docker's default configuration used to be socket activated under
systemd -- this was changed because it meant on-reboot that you wouldn't have
any containers running until someone tried to do an administrative command
(that used docker.sock).

Socket activation is more meant to allow for on-demand starting of services
without losing connections -- and the design shows that this is the main
purpose. For many services, "having a connection" doesn't mean the service is
ready yet.

I think that having a notification system for a service to tell the init
system it is ready would be nice, though the "obvious" way of doing it (rt
signals) wouldn't work for unprivileged services.

~~~
Spivak
But in systemd there's no reason you can't have a service enabled on boot and
socket activation. It's a little redundant but it can be good to catch some
corner cases: like you can always issue docker commands even if Docker isn't
ready.

