Red Hat Bugzilla – Bug 1109927
RFE: take systemd inhibitor lock while doing operations that shouldn't be interrupted by shutdown
Last modified: 2016-01-12 19:33:05 EST
If installing and or removing packages is interrupted, the system can be left in a bad state. DNF should take a systemd shutdown inhibitor delay lock (see http://www.freedesktop.org/wiki/Software/systemd/inhibit) when doing anything that can't safely be interrupted.
Rpm >= 4.12 has a plugin to do this on rpm level so it shouldn't be necessary to add it to DNF. Doing it doubly shouldn't hurt anything though.
(In reply to Panu Matilainen from comment #1)
> Rpm >= 4.12 has a plugin to do this on rpm level so it shouldn't be
> necessary to add it to DNF. Doing it doubly shouldn't hurt anything though.
Panu, how does one activate that plugin?
(In reply to Matthew Miller from comment #2)
> Panu, how does one activate that plugin?
You dont, as rpm >= 4.12 is not released yet :) Plugin configuration details is actually one of the final pieces holding that back, so the answer is "not entirely clear yet". But eventually I suppose that'd be simply a matter of having the appropriate plugin package installed, and probably such a package should get installed by default on normal systems.
Great, moving to RPM.
Moving this to RPM might be okay, but we're still left with the question of how it should be activated. Possibly the DNF packages should require the plugin?
Now that rpm 4.12 (prerelease) is in f21/f22... the plugin is activated by simply installing it and I'd think that's how we want to keep it. So, how to actually pull it in?
Dnf could require the plugin (rpm-plugin-systemd-inhibit), or another possibility could be just adding the plugin to comps at a suitable spot to avoid creating a hard dependency for something that isn't *strictly* needed. If/when weak dependencies are permitted in Fedora and dnf & friends look at them, we can probably just have rpm itself soft-require it.
Maybe in the meantime it should just be added to the standard group in comps? (Or maybe even core?)
Standard group in comps seems reasonable to me, core is a bit much as it drags in dbus ... except that core already drags in dbus, so it doesn't actually matter.
(In reply to Panu Matilainen from comment #8)
> Standard group in comps seems reasonable to me, core is a bit much as it
> drags in dbus ... except that core already drags in dbus, so it doesn't
> actually matter.
Well systemd uses dbus so you cannot really have a system without dbus. The issue with only adding it to comps is that people that upgrade from a previous fedora release wont get it.
Given that there is hardly any reason to remove it (diskspace?) I'd say just have something depend on it.
Ah, I keep forgetting systemd. Still there are the cases like containers and other chroot-cases where you dont have systemd either so dragging in the plugin and dbus would be pointless anyway, and the "minimalist" folks would complain. So... we'd actually want to have it installed whenever systemd is, but having systemd require is just completely wrong too. Can't be correctly expressed with good ol' requires.
A simple and effective solution (covering updates and all) is to have dnf require rpm-plugin-systemd-inhibit, reassigning back to dnf. Just remember this is only available in Fedora >= 21.
DNF in the upstream requires rpm-plugin-systemd-inhibit. Thanks, Panu.
dnf-0.6.3-2.fc21,dnf-plugins-core-0.1.4-1.fc21,hawkey-0.5.2-1.fc21 has been submitted as an update for Fedora 21.
Package dnf-0.6.3-2.fc21, hawkey-0.5.2-1.fc21, dnf-plugins-core-0.1.4-1.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing dnf-0.6.3-2.fc21 hawkey-0.5.2-1.fc21 dnf-plugins-core-0.1.4-1.fc21'
as soon as you are able to.
Please go to the following url:
then log in and leave karma (feedback).
dnf-0.6.3-2.fc21, hawkey-0.5.2-1.fc21, dnf-plugins-core-0.1.4-1.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.