[systemd-devel] suggestion: auto reload as the default to help packagers?

[Lennart Poettering]

On Do, 30.05.19 08:16, Roger Pack (rogerdpack2 at gmail.com) wrote:

> Seeing as one goal of systemd is to DRY up installation and running of
> services so that people can't "accidentally mess things up" through
> their own init.d files...perhaps that principle could be expanded upon
> to help make it so that package creators also can't "accidentally mess
> things up"?  Maybe the default could be to reload units automatically,
> ?  With a configuration option to not to, so that package creators
> don't *all* have to remember to daemon-reload, since not all do?

This is not really feasible on Linux. Linux does not have a
transactional file system. This means we never really know when a set
of changes made to the fs is complete or when it's ongoing. If we
reload instantly and automatically whenever we see a change
happeneing, then we might end up reloading at the wrong times: when
files are half written, when upgrades still happen and some files are
updated and others are not.

Automatic reloading of daemons on configuration changes is something
that is safe only in very simple, isolated cases, i.e. where you are
sure that the writers of the files do so in an "atomic" fashion,
i.e. create the files under a hidden, temporary name, write it in
full, then move it into place, and where files are comprehensive on
their own, i.e. bear no relationship to other files that might be
updated in sync. systemd isn't like that, we neither know how people
write their files, nor are unit files stand-alone (they configure a
dependency tree after all).

Hence, if we had a safe way how changes to the fs would always be
transaction based, i.e. executed as a whole or not at all, and we only
get notification after each transaction is complete and only see the
result of completed transactions then we could do things like this,
but without that it's always going to create more problems than it
solves.

On current Linuxes the assumption tends to be that there's only one
RPM instance or one admin running at a time, and that they schedule
the configuration reload when they think there work is complete. It's
basically a transaction logic by linerarization and move the burden to
manage this onto the user/package manager.

Sorry,

Lennart

--
Lennart Poettering, Berlin