Am 25.09.21 um 18:46 schrieb Vasyl Gello:
Hi Michael,

 >daemon-reload is a costly operation, so we should try to avoid calling it
too excessively.
 >
 >So I'm not convinced it is a good idea to generate a daemon-reload (via
dh_installsystemd in postinst) for packages which do not actually (re)start
a unit as part of the upgrade process.
 >
 >By using "--no-enable --no-start" you are basically leaving the
management of the life cycle of the service entirely to the administrator.
Wouldn't you agree?
 >
 >Shouldn't the administrator then call "systemctl daemon-reload" as well?
 >systemd will even warn him in cases a .service file has changed (which
thankfully doesn't happen too often)
 >
 >Is this actually an issue in practice? Do you have bug reports where
users of your xpra package have asked for this?

I realize daemon-reload is a costly operation, and I also realize the unit
in question is used by proxy module of Xpra, which is optional.

That's why Dmitry intentionally left it for system administrators to
configure.

Your point that typically units are not changed daily is also perfectly
valid.

However, speaking of "Shouldn't the administrator then call "systemctl daemon-reload" as well?"… No, if one uses unattended-upgrades or any other automation like auter or puppet etc.

Server gets rebooted or service gets restarted and start-up fails due to requirement of "daemon-reload" or worse, starts with previous configuration which fails too.

A reboot is not relevant here.
And if you use an automation framework like puppet, you can just as well add a daemon-reload there if you manage the service via puppet.

What I suggest is slightly different Debian-wise. We do have list of conffiles and list of files installable by the package. What prevents us from scanning the list for known locations of systemd units ({/usr}/lib/systemd/{system,user}?) and compare them by hash or by diff just like we do it with conffiles? If the units, timers, etc differ, we call daemon-reload and issue a warning to stderr so both user or script catches it. Of course it may need some additions to dpkg and debhelper (or to plain debhelper only?) but this issue will be eradicated for all packages
rebuilt after the update.

systemd already warns you, if you (manually) try to restart a service that has been modified on disk.
So I don't see the use case here.

Again, you you have any bug reports where users actually ask for this?


Attachment: OpenPGP_signature
Description: OpenPGP digital signature

Reply via email to