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.
Re-assigning for comments.
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...
>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.
Lennart, do you think that GNOME should check the enabled status of packagekit-offline-update.service before even downloading updates?
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.
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.
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.
We should verify that this is not an issue anymore.
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.
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.
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.
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.
This should be fixed, at least in current versions.
Or maybe not, somebody should check this.
@(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...
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.
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.
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
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.
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.