Re: Debian systemd survey
Marc Haber <email@example.com> writes:
> Russ Allbery <firstname.lastname@example.org> wrote:
>> Get rid of some of that complexity because it is pointless (you'll find
>> that much of it is working around inadequacies in sysvinit).
For example, all the PID file handling is working around the inability to
determine via better mechanisms whether or not the daemon is running.
Much of the logic for changing users can be eliminated in favor of a
declarative syntax. Various logic for determining whether the daemon is
installed can be handled via a better syntax or by having the base unit
file not be a configuration file (I prefer the upstart approach here,
Also, determining which flags to pass to the daemon from some other
configuration file, which is a common use of /etc/default files, is a hack
to work around the fact that an init script is not really user-editable.
We therefore move the parts that we expect users to change into a
separate, simpler configuration file to avoid making them brave the
dangers of the init script and deal with lots of dpkg configuration file
prompts when we fix bugs in the init script. But with a systemd or
upstart configuration file, it becomes reasonable to have the user just
edit that file directly to pass different parameters to the daemon, since
the configuration file is already as simple, in many cases, as the
/etc/default file was.
>> Get rid of more of it by building a static configuration from the
>> dynamic configuration when it changes, where appropriate.
> So you are seriously suggesting to add an inotify trigger on the conf.d
> directory instead of building the configuration right before it is
Could you please find a better way of asking questions than putting a
bunch of words in someone else's mouth that you clearly find absurd? It
puts the conversation on a very uncomfortable footing and leaves me
feeling like your goal is to discredit other participants in the
conversation rather than understand what they were trying to say.
I was thinking of cases where the /etc/default file or some similar
configuration file is managed by debconf, such as with one of my packages
(openafs-client). In those cases, systemd or upstart allows removing
several levels of indirection and just generating the configuration file
for the init system directly, instead of having an init script that loads
configuration from another configuration file managed by debconf.
In particular, both upstart and systemd configuration files can be fairly
easily read by maintainer scripts, allowing us to preserve user settings
that were made manually on the system, a requirement for configuration
files. This is much harder to do with init scripts, which accounts for
another chunk of the separation of init script and startup configuration.
When the source of the configuration is debconf, we know exactly when it
changes and don't need anything like inotify to know when to rebuild it.
And if the output of that configuration file is an init system
configuration that is also user-editable (which init scripts really
aren't), that allows us to also support direct user edits of the
underlying configuration without any additional complexity.
Russ Allbery (email@example.com) <http://www.eyrie.org/~eagle/>