1. 6
  1.  

  2. 1

    When did we start calling these things ‘services’ and not ‘daemons’?

    The distinction isn’t particularly useful here, so I’ll use the terms unit, target, and service more-or-less as synonyms.

    This is strange. As I understand it, what systemd call a ‘target’, virtually everything else call a ‘runlevel’, and it’s really a very different concept to ‘daemon’ or ‘service’.

    race condition (nothing prevents a dependency from stopping just after the check is made)

    How is this any different from a dependency crashing at any other time during the running of the dependent service?

    1. 2

      When did we start calling these things ‘services’ and not ‘daemons’?

      It’s ironic you ask that because the “d” in systemd stands for daemon.

      1. 1

        When did we start calling these things ‘services’ and not ‘daemons’?

        In my view a ‘service’ is potentially implemented as multiple ‘daemons’, or even none at all (though perhaps ‘service’ isn’t really a good name for the latter case and then I suppose ‘unit’ might be more appropriate).

        This is strange. As I understand it, what systemd call a ‘target’, virtually everything else call a ‘runlevel’, and it’s really a very different concept to ‘daemon’ or ‘service’.

        I disagree that they are a very different concept. Targets are units; they can depend on other units; other units can depend on them; there’s nothing particularly special about Systemd’s targets; all the same commands work on both targets and other units, all the general concepts apply to both. I also don’t agree that targets are synonymous with runlevels - rather, targets can be used to emulate the concept of runlevels.