Hi,

Not sure if this should be reported here or in dpkg

Shouldn't it be intresting to add a hook in dpkg to inhibit the
reboot/shutdown of the machine while packages are being
updated/installed?

Kind regards,

Laurent Bigonville

Am 05.10.18 um 18:36 schrieb Laurent Bigonville:


I don't see how this could be implemented via a dpkg hook.
Can you elaborate, maybe provide a hook file which implements what you
have in mind?

That said, also keep in mind, that the inhibit mechanism does not work
if the reboot request is triggered by privileged users [1], e.g. if you
trigger a reboot as root, an existing inhibitor blocks are ignored.

Michael

[1] https://github.com/systemd/systemd/issues/6644

Am 05.10.18 um 21:28 schrieb Michael Biebl:

This issue describes this even better
https://github.com/systemd/systemd/issues/2680

It seems there is no real interest to change this upstream and even if
at some point in the future there was a way to make inhibitors work for
the root user, I think such an inhibitor lock shoud be take directly by
dpkg.  I don't think the hook interface is sufficient for that.

Regards,
Michael

reopen 910377
reassign dpkg 1.20.9
thanks
work
if you

I'm reopening this issue and reassigning it dpkg package, that would at
least avoid non privileged users to restart the machine when there is an
update happening.

Apparently RPM has this functionality via a plugin. The manpage of the
plugins available at [0] and says:

        This plugin for RPM prevents the system to enter shutdown, sleep
        or idle mode while there is a rpm transaction running to prevent
        system corruption that can occur if the transaction is
        interrupted by a reboot.

        This is achieved by using the inhibit DBUS interface of systemd.
        The call is roughly equivalent to executing

        systemd-inhibit --mode=block --what=idle:sleep:shutdown --who=RPM
        --why="Transaction running"

The code is available in [1]

Having something similar in dpkg would be nice, but that would mean that
dpkg will grow a dependency on libdbus and/or libsystemd, not sure how
that would work

[0] https://man7.org/linux/man-pages/man8/rpm-plugin-systemd-inhibit.8.html
[1]
https://github.com/rpm-software-management/rpm/blob/master/plugins/systemd_inhibit.c

Laurent Bigonville writes:

For what it's worth apt supports this already when apt invokes dpkg:

```C++
         if (_config->FindB("DPkg::Inhibit-Shutdown", true))
            Fd = Inhibit("shutdown", "APT", "APT is installing or removing packages", "block");
```

Ansgar

Or just use apt which already does this instead of manually running
dpkg? I mean, it wouldn't hurt to have dpkg inhibit too, but it's not
really relevant for most users given that apt-pkg library does and hence
apt, aptitude, packagekit.

[ CCing #910377 for some context. ]

Hi!

I guess one case that this does not cover is when the user initiates a
shutdown/reboot, and an external superuser might be performing remote
package management on that system.

But in that case, that same superuser can use a frontend that already
inhibits those actions (such as apt), or on systems using systemd can
run dpkg via systemd-inhibit.

Well dpkg is supposed to be resilient against system crashes, abrupt
shutdowns or reboots anyway, breakage in dpkg in those cases (but not
due to specific handling from within some other package) should be
considered bugs in dpkg.

Both are protected by dpkg and apt, for dpkg just with different
--force-<foo> options, so that you can control which one to let through.

Agreed.

apt already does this, so any other frontend using libapt or apt
directly will get this automatically.

While dpkg on systems using systemd _could_ by default take an
system inhibitor lock, and could provide a good enough reason like say
"Packaging system upgrade" or whatever, my concern has been with the
added dependency chain, and after reading your mail and thinking about
this now, I have to agree this seems like a higher level policy.
(Of course dpkg could also do that and grow a new --no-inhibit,
or --refuse-inhibit or similar option, but still.)

But then, I recalled I had a git branch adding a dpkg-db-lock command
with a --wait-lock option, that I could recover and polish to provide
an example pre-hook script that would call that via a background
systemd-inhibit if systemd is running and the command is available,
where an admin that wanted to do that for their system or fleet of
systems could hook into the dpkg config. I've done that locally, and
will check whether that's viable and probably merge it for 1.22.1
or 1.22.2, so that people that want to do it can easily do so.

Thanks,
Guillem

I'm not sure how that works because you'd need to respawn yourself
with systemd-inhibit, whereas the API essentially gives you a file
descriptor over dbus that you keep open until it is safe to reboot.

Hi,

     popen("systemd-inhibit ... cat", "w");

should work.

    Simon