Re: [systemd-devel] Question about system-update.target
This seems to putthe requirement of an If(a||b||c)==Failure Then reboot.target Where a b and c are ALL required to complete before rebooting occurs. I would thing to specifically handle each tool as a process, Would a specific script or tool already be available? Is it possible to one-shot async run given services using systemctl then afterwards pull status and log the individual failure before restarting as a desired behavior here? Personally I would make a custom service as the update target and specifically have it failover to reboot once ALL depends have been run as one-shot fire-until-finished-with-exit strategy. Hopefully I am understanding the issue with a possible execution strategy for this specific case? Is it even practical with current tools in some way? On 27/04/2015 5:52 PM, Richard Hughes hughsi...@gmail.com wrote: At the moment the only user of system-update.target is PackageKit, which does package updates offline in the special system-update boot target. The other project that has just started using this mode is fwupd, which is using it to update BIOS-based firmware (not UEFI capsules) offline. I've installed a symlink to system-update.target.wants so that the fwupd process gets run, but I'm a little worried about what happens when there are two optional services being run, both with OnFailure=reboot.target What return code I supposed to return if we launch fwupd-offline-update.service and there are no BIOS updates to apply? It seems to me that we want the behaviour of OnFailure to be if none of the *-offline-update.service files returned success rather than what happens now in that we launch pk-offline-update with no package updates which returns failure, which reboots the machine before the fwupd offline update process even gets a chance to properly start. Ideas welcome, thanks. Richard ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Question about system-update.target
At the moment the only user of system-update.target is PackageKit, which does package updates offline in the special system-update boot target. The other project that has just started using this mode is fwupd, which is using it to update BIOS-based firmware (not UEFI capsules) offline. I've installed a symlink to system-update.target.wants so that the fwupd process gets run, but I'm a little worried about what happens when there are two optional services being run, both with OnFailure=reboot.target What return code I supposed to return if we launch fwupd-offline-update.service and there are no BIOS updates to apply? It seems to me that we want the behaviour of OnFailure to be if none of the *-offline-update.service files returned success rather than what happens now in that we launch pk-offline-update with no package updates which returns failure, which reboots the machine before the fwupd offline update process even gets a chance to properly start. Ideas welcome, thanks. Richard ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Question about system-update.target
On Mon, 27.04.15 09:52, Richard Hughes (hughsi...@gmail.com) wrote: At the moment the only user of system-update.target is PackageKit, which does package updates offline in the special system-update boot target. The other project that has just started using this mode is fwupd, which is using it to update BIOS-based firmware (not UEFI capsules) offline. I've installed a symlink to system-update.target.wants so that the fwupd process gets run, but I'm a little worried about what happens when there are two optional services being run, both with OnFailure=reboot.target Well, thinking about this, maybe OnFailure=reboot.target is missing the point for these services. After all, the system should reboot regardless if the update fails or not... So maybe add a service systemd-update-post.service or so, that uses: [Service] Type=oneshot ExecStart=/bin/systemctl reboot --no-block Then make sure that all your update services are of Type=oneshot themselves and use Before=system-update-post.service and Wants=system-update-post.service? This would mean that any updating service would pull this in, and order itself before it. Sicne this new service is hence ordered efter each updating service it will only run after all of them finished, regardless if failed or succeeded. Does this make sense to you? If so, we could probably add system-update-post.service as a standard service to systemd itself. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Question about system-update.target
On 27 April 2015 at 15:18, Lennart Poettering lenn...@poettering.net wrote: Well, thinking about this, maybe OnFailure=reboot.target is missing the point for these services. After all, the system should reboot regardless if the update fails or not... Not quite; PackageKit supports an update-offline-and-then-shutdown mode at the request of the GNOME designers. If we can configure that using systemd I'd gladly rip out the code in PackageKit and move it down to systemd. This would mean that any updating service would pull this in, and order itself before it. Sicne this new service is hence ordered efter each updating service it will only run after all of them finished, regardless if failed or succeeded. Does this make sense to you? Sure, it does, modulo the feature above. Richard. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Question about system-update.target
On 27 April 2015 at 16:42, Lennart Poettering lenn...@poettering.net wrote: - ship a service packagekit-reboot.service that contains: [Service] ExecStart=/bin/systemctl reboot --no-block Type=oneshot If that file was shipped in systemd, fwupd could use the same method without having to ship the extra duplicated files. e.g. system-update-post-reboot.service Then, order both your update services Before=packagegit-reboot.service packagekit-poweroff.service, so that they run before those services are started. Makes sense so far. Finally, from packagekit, enqueue pretty early on, before you start installation either one or the other of the two services, depending on packagkit's configuration. This is easily done by issuing the StartUnit() bus call on the systemd service file passing either packagekit-reboot.service or packagekit-poweroff.service as first parameter, and replace as second. Clever stuff. I hope that makes sense? and remove OnFailure=reboot.target, right? Richard. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Question about system-update.target
On Mon, 27.04.15 15:47, Richard Hughes (hughsi...@gmail.com) wrote: On 27 April 2015 at 15:18, Lennart Poettering lenn...@poettering.net wrote: Well, thinking about this, maybe OnFailure=reboot.target is missing the point for these services. After all, the system should reboot regardless if the update fails or not... Not quite; PackageKit supports an update-offline-and-then-shutdown mode at the request of the GNOME designers. If we can configure that using systemd I'd gladly rip out the code in PackageKit and move it down to systemd. Hmm, in that case I think this is best done as part of PackageKit really... Something like this: - ship a service packagekit-reboot.service that contains: [Service] ExecStart=/bin/systemctl reboot --no-block Type=oneshot - ship a service packagekit-poweroff.service that contains: [Service] ExecStart=/bin/systemctl poweroff --no-block Type=oneshot Then, order both your update services Before=packagegit-reboot.service packagekit-poweroff.service, so that they run before those services are started. Finally, from packagekit, enqueue pretty early on, before you start installation either one or the other of the two services, depending on packagkit's configuration. This is easily done by issuing the StartUnit() bus call on the systemd service file passing either packagekit-reboot.service or packagekit-poweroff.service as first parameter, and replace as second. That way you can keep the setting hwether to reboot or poweroff in packagekit. And make sure to enqueu the jobs really early on, so that they are enqueued whatever happens. the deps will make sure that they aren't run before your two updat services actually finish running. I hope that makes sense? Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Question about system-update.target
On 27 April 2015 at 17:53, Mantas Mikulėnas graw...@gmail.com wrote: In this case, failure doesn't make much sense, if you describe the task as ensuring that the BIOS is up-to-date. In this case, the task is upload firmware blob foo.bin in /var/cache to the flash chip Richard. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Question about system-update.target
On Mon, Apr 27, 2015 at 11:52 AM, Richard Hughes hughsi...@gmail.com wrote: What return code I supposed to return if we launch fwupd-offline-update.service and there are no BIOS updates to apply? In this case, failure doesn't make much sense, if you describe the task as ensuring that the BIOS is up-to-date. -- Mantas Mikulėnas graw...@gmail.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
