What 'dependency' means in Unix init systems is underspecified

I was reading Davin McCall's On the vagaries of init systems ( via ) when I ran across the following, about the relationship between various daemons (services, etc):

I do not see any compelling reason for having ordering relationships without actual dependency, as both Nosh and Systemd provide for. In comparison, Dinit’s dependencies also imply an ordering, which obviates the need to list a dependency twice in the service description.

Well, this may be an easy one but it depends on what an init system means by 'dependency'. Let's consider (r)syslog and the SSH daemon. I want the syslog daemon to be started before the SSH daemon is started, so that the SSH daemon can log things to it from the beginning. However, I very much do not want the SSH daemon to not be started (or to be shut down) if the syslog daemon fails to start or later fails. If syslog fails, I still want the SSH daemon to be there so that I can perhaps SSH in to the machine and fix the problem.

This is generally true of almost all daemons; I want them to start after syslog, so that they can syslog things, but I almost never want them to not be running if syslog failed.

(And if for some reason syslog is not configured to start, I want enabling and starting, say, SSH, to also enable and start the syslog daemon.)

In general, there are three different relationships between services that I tend to encounter:

• a hard requirement , where service B is useless or dangerous without service A. For instance, many NFS v2 and NFS 3 daemons basically don't function without the RPC portmapper alive and active. On any number of systems, firewall rules being in place are a hard requirement to start most network services; you would rather your network services not start at all than that they start without your defenses in place.
• a want , where service B wants service A to be running before B starts up, and service A should be started even if it wouldn't otherwise be, but the failure of A still leaves B functional. Many daemons want the syslog daemon to be started before they start but will run without it, and often you want them to do so so that at least some of the system works even if there is, say, a corrupt syslog configuration file that causes the daemon to error out on start.

  (But some environments want to hard-fail if they can't collect security related logging information, so they might make rsyslogd a requirement instead of a want .)

• an ordering , where if service A is going to be started, B wants to start after it (or before it), but B isn't otherwise calling for A to be started. We have some of these in our systems, where we need NFS mounts done before cron starts and runs people's @reboot

  jobs but neither cron nor NFS mounts exactly or explicitly want each other.

  (The system as a whole wants both, but that's a different thing.)

Given these different relationships and the implications for what the init system should do in different situations, talking about 'dependency' in it systems is kind of underspecified. What sort of dependency? What happens if one service doesn't start or fails later?

My impression is that generally people pick a want relationship as the default meaning for init system 'dependency'. Usually this is fine; most services aren't actively dangerous if one of their declared dependencies fails to start, and it's generally harmless on any particular system to force a want instead of an ordering relationship because you're going to be starting everything anyway.

(In my example, you might as well say that cron on the systems in question wants NFS mounts. There is no difference in practice; we already always want to do NFS mounts and start cron.)