This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 830181 - Logout/shutdown/restart should be inhibited while Apper is performing updates
Logout/shutdown/restart should be inhibited while Apper is performing updates
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: PackageKit (Show other bugs)
18
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Richard Hughes
Fedora Extras Quality Assurance
RejectedNTH
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-08 09:18 EDT by Kamil Páral
Modified: 2015-06-04 16:39 EDT (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-12-11 04:41:44 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
auto-update in apper (55.00 KB, image/png)
2012-09-14 07:42 EDT, Kamil Páral
no flags Details

  None (edit)
Description Kamil Páral 2012-06-08 09:18:43 EDT
Description of problem:
This is a fork of bug 755335. In F17 we switched the option to disable auto-update by default. We need something better for F18. Either the problem should be fixed (see proposed solutions in bug 755335), or the auto-update option should not be available at all.

Steps to Reproduce:
1. have auto-update enabled
2. wait until updates are being installed
3. reboot the computer
4. see broken rpm database, etc

Marking as F18 Alpha blocker, so that we have enough time to discuss the blocker-ness and the appropriate milestone.
Comment 1 Richard Hughes 2012-08-03 02:40:23 EDT
As from F18, we're doing this: http://freedesktop.org/wiki/Software/systemd/SystemUpdates -- see https://fedoraproject.org/wiki/Features/OfflineSystemUpdates for details.
Comment 2 Kamil Páral 2012-08-03 03:55:30 EDT
Richard, that wiki page talks about "system updates", and you're right, that should be solved - in GNOME.

1. What about application updates in GNOME, how will they be handled? Can I enable auto-update of application updates? Will they be installed on the running system (F17 behavior) or after restart (offline-updates)?

2. What about system updates in KDE/XFCE/elsewhere? Is this solved as well? Or the situation is completely the same as in F17 - users can enable auto-update in their settings and that can possibly break their system afterwards? In that case this bug wouldn't be fixed.

3. Can you we - the QA - learn what's included in system updates and what's included in application updates? We need to know which package is considered which update type, so that we can check everything works as expected.

Thanks.
Comment 3 Kamil Páral 2012-08-03 03:57:02 EDT
(In reply to comment #2)
> 3. Can you we - the QA - learn what's included in system updates and what's
     ^^^^^^^^^^
     How can we
Comment 4 Richard Hughes 2012-08-03 05:46:32 EDT
(In reply to comment #2)
> 1. What about application updates in GNOME, how will they be handled? Can I
> enable auto-update of application updates? Will they be installed on the
> running system (F17 behavior) or after restart (offline-updates)?

You can do either at the moment. The plan for F18 is to do all automatic updates offline, and anything user-triggered live, so to speak.

> 2. What about system updates in KDE/XFCE/elsewhere? Is this solved as well?

No clue, I'm a GNOME developer. I imagine KDE users are using apper which I think does does live-updating, although I'm not sure. XFCE/others have to run either apper or gnome-packagekit as they've got nothing native.

> Or the situation is completely the same as in F17 - users can enable
> auto-update in their settings and that can possibly break their system
> afterwards? In that case this bug wouldn't be fixed.

No, if the user doesn't disable auto-updates then the updates are downloaded in the session and updated on next boot if they select "Restart and install updates".

> 3. Can you we - the QA - learn what's included in system updates and what's
> included in application updates? We need to know which package is considered
> which update type, so that we can check everything works as expected.

If you want to force an OS update, you can use "pkcon --only-download update powertop" and then use the "Restart and install updates" when that's complete.

We've not put the time in yet to automatically work out what updates should be done offline or live yet. That's something that would probably wake the trolls on devel@fedora, so it's not something I'm looking forward to.

Richard.
Comment 5 Adam Williamson 2012-08-03 19:45:25 EDT
Dropping the block on F18Alpha, as it shows up as a proposed blocker even though it's closed.

If we are worried about the situation wrt KDE, Xfce and LXDE, we should evaluate each spin and file new bugs against the relevant components as appropriate. I believe KDE uses apper, which does live updates, but I don't know offhand if it has a 'silent auto-update' option. I believe the Xfce and LXDE spins use yumex; again, not sure what the auto-update options are there. Kamil, do you want to take charge of checking this out with the other supported desktops? Thanks!
Comment 6 Kamil Páral 2012-08-06 09:00:37 EDT
(In reply to comment #5)
> Kamil, do you want to take charge of checking this out with the other
> supported desktops? Thanks!

Yes, I'll do that once we have some test compose.
Comment 7 Adam Williamson 2012-08-07 19:50:18 EDT
Checking with F17 ought to be fine, really, I don't think any desktop has changed its package manager between 17 and 18.
Comment 8 Kamil Páral 2012-09-14 07:41:53 EDT
I checked all DEs. GNOME is fine, it no longer offers the option to auto-update, instead it uses offline-updates. XFCE and LXDE doesn't use gnome-packagekit at all and yumex doesn't seem to support auto-update.

The only problem is in KDE, where auto-update is disabled by default, but it is still available (see screenshot). The user can change this setting and then end up with a broken system one day. Reassigning to apper (as I understand it is the correct component in KDE).

Proposing as F18 Final NTH.
Comment 9 Kamil Páral 2012-09-14 07:42:20 EDT
Created attachment 612822 [details]
auto-update in apper
Comment 10 Rex Dieter 2012-09-14 07:46:11 EDT
If I understand correctly, you're proposing that the ability to auto-install  anything in apper be removed? (or if something else, please do explain further)
Comment 11 Rex Dieter 2012-09-14 07:53:12 EDT
OK, read over bug  #755335 , the issue at hand seems to be that when auto-install feature is enabled, shutting down during updates installing =>  fail.  no argument there.

I'm not sure that warrants too drastic an action for something that's clearly user-error, but will think about it some more.
Comment 12 Kamil Páral 2012-09-14 08:12:01 EDT
(In reply to comment #10)
> If I understand correctly, you're proposing that the ability to auto-install
> anything in apper be removed? (or if something else, please do explain
> further)

Yes, I believe the whole drop-down list should be removed until we have a safe way to do auto-updating. That means the system should refuse to shut down if auto-update process is running.

(In reply to comment #11)
> I'm not sure that warrants too drastic an action for something that's
> clearly user-error, but will think about it some more.

It's not really a user-error. User doesn't know about auto-updating taking place, it's happening in the background, as requested. Does KDE have some highly visible pop-up to alert the user that the system is being updated and it shouldn't be shut down until it is finished? If not, there is no way how the user could know that he's not supposed to shut down the system (that was the case for GNOME 3.4).
Comment 13 Rex Dieter 2012-09-14 08:17:17 EDT
There is a notification when updates start and are underway, but it probably doesn't count as "highly visibible"
Comment 14 Lukáš Tinkl 2012-09-14 08:24:46 EDT
I'm pretty sure apper will set an inhibition on shutdown/reboot when an update is underway; doesn't prevent you from pulling the plug manually of course :)
Comment 15 Kamil Páral 2012-09-14 08:49:26 EDT
I just tested with F18 Alpha RC3 KDE. It shows exactly the same symptoms as described in bug 755335. I asked apper to auto-install all updates, set hourly check and waited with 'ps aux | grep yum' for packagekit to begin installation. Once it did (a system popup also appeared), I waited until it applied deltarpms and started real installation. Then I powered off the machine correctly using the menus. There was no warning, no inhibitor.

After reboot, 'yum history' reports broken update and 'yum check' reports 25 errors - duplicate packages.

Maybe apper inhibitor no longer works?
Comment 16 Lukáš Tinkl 2012-09-14 10:31:00 EDT
acked, getting this cleared up with dantti (the apper's author)
Comment 17 Kevin Kofler 2012-09-14 11:20:37 EDT
Adjusting summary to describe the real issue.

That said, this doesn't look like a serious issue to me. For one, automatic updates are not enabled by default (and for manual updates, you hopefully won't shutdown your machine while running them), and secondly, the messed-up state can usually be fixed using yum-complete-transaction or yum history redo.
Comment 18 Adam Williamson 2012-09-17 20:50:16 EDT
kk: it's true that it's not the default state, and so we're much less worried than we were about the GNOME incarnation. your second statement is likely untrue though, there's all sorts of ways a yum/rpm process that's killed without warning can go wrong which can't be fixed with those commands.
Comment 19 Rex Dieter 2012-10-03 10:44:38 EDT
Discussed on irc at length over the last couple of days with ltinkl and dannti (with here-say comments from hughsie), and came to the conclusion that packagekitd either is or *should be* the best place to handle systemd inhibits when packagekitd is processing stuff.  

(that should naturally handle all PK-frontends, including pkcon too).

Please correct me if my characterization of discussions or facts is incorrect.

reassigning => PackageKit
Comment 20 Adam Williamson 2012-12-19 13:41:24 EST
Discussed at 2012-12-19 NTH review meeting: http://meetbot.fedoraproject.org/fedora-bugzappers/2012-12-19/f18final-blocker-review-6.2012-12-19-17.02.log.txt . We agreed we're wary of taking major PackageKit changes this late to fix a bug which isn't critical (as noted above it's different from the F17 GNOME case because auto-update is not the default config), so this is rejected as NTH - if this is going to be done we'd like it to be done in the normal course of development, not as a last minute fix.

Note You need to log in before you can comment on or make changes to this bug.