Re: Bug#910377: Inhibit reboot/shutdown if dpkg is running
- To: email@example.com
- Cc: Dpkg Developers <firstname.lastname@example.org>
- Subject: Re: Bug#910377: Inhibit reboot/shutdown if dpkg is running
- From: Laurent Bigonville <email@example.com>
- Date: Wed, 19 May 2021 16:03:16 +0200
- Message-id: <[🔎] firstname.lastname@example.org>
- In-reply-to: <email@example.com>
- References: <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com>
reassign dpkg 1.20.9
On Sat, 31 Aug 2019 00:34:32 +0200 Michael Biebl <firstname.lastname@example.org> wrote:
On Fri, 5 Oct 2018 21:30:43 +0200 Michael Biebl <email@example.com> wrote:
> Am 05.10.18 um 21:28 schrieb Michael Biebl:
> > That said, also keep in mind, that the inhibit mechanism does not
> > if the reboot request is triggered by privileged users , e.g.
> > trigger a reboot as root, an existing inhibitor blocks are ignored.
> >  https://github.com/systemd/systemd/issues/6644
> This issue describes this even better
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.
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
Apparently RPM has this functionality via a plugin. The manpage of the
plugins available at  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
The code is available in 
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