Dear Maintainer(s),

systemd v248 will ship with a new dbus/systemctl interface to mark a
unit as needing reload/restart, and a new dbus/systemctl to queue all
reload/restart jobs in a single command.
The RPM packaging/scripts are changing to use this instead of custom
batching.

I'm opening this ticket to explore whether it would be
possible/good/desirable to switch the debhelper tools to use this as
well in the future.

It looks like this:

systemctl set-property foo.service Markers=needs-restart
systemctl set-property bar.service Markers=needs-reload
...
systemctl reload-or-restart --marked

(or equivalent DBUS calls)

References:

https://github.com/systemd/systemd/commit/ff68472a20c208121b69ea13586f3105a219bc14
https://github.com/systemd/systemd/commit/c9615f73521986b3607b852c139036d58973043c
https://github.com/systemd/systemd/pull/18481/commits

The advantage being, you can mark a unit inline, but then batch the
actual jobs later/asynchronously.

Note that, given the interface has just been merged and is not yet
released, there is scope for improvements if there are debhelper-
specific concerns to address, given the feature first use is the RPM's
side of things.

Thoughts?

Luca Boccassi:

By the sound of it, this is something that might need to go into the
init system helpers that debhelper invokes in the maintscripts (possibly
with a trigger in the systemd side to do the batch reload/restart).

@Michael: What is your view?

~Niels

Reassigning to init-system-helpers, quoting in full for the
init-system-helpers maintainer's sake.

Hi!

Not Michael, but if I can offer my thoughts, this is not something that
could be done in i-s-h (or at least, not something that we could do
transparently). This is because presumably there are postinst scripts that
assume post-debhelper-block the new version is already running. So I
believe what would be needed is:

1. Support in i-s-h to activate this mode, probably via a new flag.
2. Support in debhelper to enable/disable this new method.
3. A trigger in systemd to do the final reload.

I believe requiring the new daemon version to be already updated by
postinst time would be quite rare, so I think point 2 could be enabled by
default in a new compat level.

Thoughts?

Felipe Sateler:


Hi,

From a debhelper PoV, that seems fine to me if the systemd side can
support it (the trigger part).

~Niels