Bug 988235 - boot hangs at system-update.target when packagekit-offline-update.service is disabled
boot hangs at system-update.target when packagekit-offline-update.service is ...
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: PackageKit (Show other bugs)
24
Unspecified Linux
unspecified Severity medium
: ---
: ---
Assigned To: Richard Hughes
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-25 03:22 EDT by Elliott Forney
Modified: 2017-08-08 07:42 EDT (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-08-08 07:42:29 EDT
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)

  None (edit)
Description Elliott Forney 2013-07-25 03:22:02 EDT
Description of problem:

When offline updates are disabled by turning off packagekit-offline-update.service in systemd it is still possible for offline updates to be triggered, causing boot to hang at system-update.target

Version-Release number of selected component (if applicable):

Fedora release 19 (Schrödinger’s Cat)
PackageKit-0.8.9-6.fc19.x86_64
systemd-204-9.fc19.x86_64

How reproducible:

Whenever updates are available.

Steps to Reproduce:

1.  Disable the packagekit-offline-update.service
  systemd disable packagekit-offline-update.service
  systemd stop packagekit-offline-update.service

2.  Log in to gnome-shell

3.  When updates are available, log out of gnome-shell with "Install updates and reboot"

4.  This creates a symlink /system-update -> /var/cache

5.  During reboot, they system hangs at system-update.target

Actual results:

Boot hangs.  Only way out of this, as far as I can tell, is to remove /system-update using a rescue image.  Will happen again next time someone logs out with "install updates" from gnome-shell.

Expected results:

If packagekit-offline-update.service is disabled, then system-update.target should be a noop.  Ideally, gnome-shell wouldn't even offer the "update with reboot" option if this service was turned off.

Additional info:

We have several hundred systems that we keep consistent using a tool similar to AIDE.  I can certainly understand the convenience of automatic updates but in this kind of environment it would be extremely difficult to keep things consistent (which helps troubleshooting and security) if all the machines are running updates all "willy nilly."  Going forward, I do hope it will be easier to disable auto-update functionality.  We already have to setup undocumented polkit rules in order to prevent users from kicking off updates.
Comment 1 Richard Hughes 2013-12-11 04:18:11 EST
Re-assigning for comments.
Comment 2 Lennart Poettering 2014-06-19 15:09:41 EDT
So, you disabled a service, and then you used functionality of that service and are surprised if it doesn't work as advertised? 

I don't think there's anything to fix here. People should simply not disable that service and expect things to work. 

Richard, two options:

a) close the bug was WONTFIX...

b) turn packagekit-offline-update.service into a statically enabled service, rather than a dynamic one. A statically enabled service is a service that cannot be turned off (unless you take the big big hammer that is "masking"), and is basically always on. Many of systemd's own core services like this. Static services do not have [Install] sections, and systemctl enable/disable will not work for them. Instead a .wants symlink is shipped with the RPM inside of /usr. Simply remove the [install] section from your service, drop the systemctl enable invocations for it from the RPM scriptlets, and instead add a symlink as normal file to the package. The symlink should be in /usr/lib/systemd/system/system-update.target.wants/packagekit-offline-update.service and point to ../packagekit-offline-update.service. Note that static services are not the way to go for normal services where it makes sense to disable them. But in this case, there isn't really a reason to disable them, and it comes at no price as normally one doesn't enter offline-update mode, so people should not be tripped off by this...

But then again, option a) is also a good one...

Anyway, reassigning back to pkgkit, as there#s nothing to do from our side...
Comment 3 Elliott Forney 2014-06-19 18:40:51 EDT
>So, you disabled a service, and then you used functionality of that service and are surprised if it doesn't work as advertised?

I don't see why my expectation is unreasonable.  If I disable the service that runs offline updates I would simply expect that offline updates would not run, without the system hanging during boot.

>I don't think there's anything to fix here. People should simply not disable that service and expect things to work.

There are many environments in which it is desirable for updates to only be run in a controlled fashion during off-peak hours, e.g., production, mission-critical and multi-user laboratory settings.

You can dismiss this issue if you like or make packagekit-offline-updates.service static to prevent it from being disabled, but the problem will remain:  there is no straightforward mechanism to disable offline updates.
Comment 4 Richard Hughes 2014-06-20 06:00:29 EDT
Lennart, do you think that GNOME should check the enabled status of packagekit-offline-update.service before even downloading updates?
Comment 5 Juan J. Martínez 2014-08-08 05:54:17 EDT
I'd love to be able to disable offline updates, but I understand that it is a core functionality of the system.

Could it be possible to configure when the automatic downloading of updates will happen? My internet connection is limited and it is quite inconvenient that I can't control when the downloading happens.
Comment 6 Fedora End Of Life 2015-01-09 17:13:29 EST
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 7 Fedora End Of Life 2015-02-18 09:02:19 EST
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 8 Zbigniew Jędrzejewski-Szmek 2015-02-18 09:14:07 EST
We should verify that this is not an issue anymore.
Comment 9 Jaroslav Reznik 2015-02-19 09:09:46 EST
Please, change the version to version bug is reproducible or is planned to be fixed. Fedora 19 is already EOL and no new updates are allowed.
Comment 10 Matthias Clasen 2015-05-28 16:25:42 EDT
If you want to prevent users from triggering offline updates, you can take away the policykit privilege that controls it: org.freedesktop.packagekit.trigger-offline-update.

I don't think there is anything to fix here.
Comment 11 Elliott Forney 2015-06-10 15:53:46 EDT
If packagekit-offline-update.service cannot be disabled without breaking the system then I might suggest that Lennart's suggestion be followed and the service be made static.

Then, if an administrator wants to prevent users from disabling the service, they can follow Matthias' suggestion use policykit to prevent offline updates from being triggered by ordinary users. (this is what we do currently).

It just worries me that the boot process can be completely broken (and need rescue) by running 'systemctl disable packagekit-offline-update.service'  My first intuition was to disable this service in order to prevent offline updates.
Comment 12 Jan Kurik 2015-12-22 06:29:18 EST
This bug is currently assigned to an unsupported release. If you think this bug is still valid and should remain open, please re-assign it to a supported release (F22, F23) or to rawhide.

Bugs which will be assigned to an unsupported release are going to be closed as EOL (End Of Life) on January 26th, 2016.
Comment 13 Zbigniew Jędrzejewski-Szmek 2016-01-26 08:38:40 EST
This should be fixed, at least in current versions.
Comment 14 Zbigniew Jędrzejewski-Szmek 2016-01-26 08:40:44 EST
Or maybe not, somebody should check this.
Comment 15 Jóhann B. Guðmundsson 2016-01-26 09:12:34 EST
@(In reply to Zbigniew Jędrzejewski-Szmek from comment #14)
> Or maybe not, somebody should check this.

This is a Gnome/Packagekit bug not a systemd one so this is not fixed ( atleast not here on F23 ). 

The fact is administrator need to jump through hoops to disable this ( like most natural things in Gnome ) and they do so due to among other things conflicts with command line updates, huge var/cache/PackageKit/metadata which can lead to unbootable system after the user got notified alot with disk warnings from Gnome but no way to free his or her space which eventually leads to /var got filled leaving the end user with unbootable system ( have had few house calls due to those <sigh> ) yata yata you know the typical thing you would expect users to be able to configure and tweak from the desktop or application settings ui even clean from the disk warning app

Administrators wont hesitate to light those torches and take that big hammer to hammer that static service Lennart suggest to solve that problem and mask it while regular end users find themselves some other OS to run or bother people like me...
Comment 16 Zbigniew Jędrzejewski-Szmek 2016-01-26 09:15:59 EST
Well, for me the bug is where the fix is. I'm think we should set things up in a way that if none of the offline-update services run, the system recovers nicely. I don't think this happens currently. I'm not sure what the best way to do this is, but the solution will most likely be in systemd itself.
Comment 17 Jóhann B. Guðmundsson 2016-01-26 10:25:01 EST
The solution will probably be downstream since systemd itself should not be participating in the falsehope to be ever able to support the gazillion means in the linux ecosystem to update/install a component and top of that downstream have already started to patch out in the masses bad upstream like references to display-manager.service etc.

Chasing that down leads to madness and I would think that the future resides in a complete image update however Fedora ( and the rest of the major distro's  ) are far from being there if they ever will be able to be there. ( DE's need to release they own OS and host and run their own app market but they either have not realized that or reluctant to go down that path  )

Back to how things are instead of how they should be, you cannot gracefully continue the system if offline updates fails, afaikt since the options you have are a) drop the end user to emergency mode and hope he has some individual like me on speed dial if shit hits the fan. b) Reboot/continue and flag system/notify the update/upgrade process somehow that it has failed ( assuming that failure did not leave the systemd un bootable in the first place )  which requires the update process somehow to be able to detect that ( which I dont think is the case now ) so the DE does immediately ask the end user to reboot again or is forced to ask him to open a terminal and perform manually update to workaround/complete that update process which ( as currently are implemented ) aren't compatible process. 

And even if it was possible you need to gracefully deal with the lack of end user patience with regards to the offline update process itself and failure of the distributions to notify him ( or notify him clear enough )  that the system is updating itself so they forcefully poweroff/on or reboot the system in middle of offline update process since it took longer than usual to reach the desktop.
Comment 18 Jan Kurik 2016-02-24 10:34:50 EST
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle.
Changing version to '24'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase
Comment 19 Fedora End Of Life 2017-07-25 14:33:27 EDT
This message is a reminder that Fedora 24 is nearing its end of life.
Approximately 2 (two) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 24. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '24'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 24 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Comment 20 Fedora End Of Life 2017-08-08 07:42:29 EDT
Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

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