systemd-stable/units/system-update-cleanup.service.in

#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

[Unit]
Description=Remove the Offline System Updates symlink
Documentation=man:systemd.special(5) man:systemd.offline-updates(7)
After=system-update.target
DefaultDependencies=no
Conflicts=shutdown.target
Before=shutdown.target

# system-update-generator uses laccess("/system-update"), while a plain
# ConditionPathExists=/system-update uses access("/system-update"), so
# we need an alternate condition to cover the case of a dangling symlink.
#
# This service is only invoked if /system-update exists, i.e. if the
# condition tested by system-update-generator remains true and the system
# would be diverted into system-update.target again after reboot. This way
# we guard against being diverted into system-update.target again, which
# works as a safety measure, but we will not step on the toes of the
# update script if it successfully removed the symlink and scheduled a
# reboot or some other action on its own.
ConditionPathExists=|/system-update
ConditionPathIsSymbolicLink=|/system-update

[Service]
Type=oneshot
ExecStart=/bin/rm -fv /system-update
ExecStart=@SYSTEMCTL@ reboot
units: add system-update-cleanup.service to guard against offline-update loops Note: the name is "system-update-cleanup.service" rather than "system-update-done.service", because it should not run normally, and also because there's already "systemd-update-done.service", and having them named so similarly would be confusing. In https://bugzilla.redhat.com/show_bug.cgi?id=1395686 the system repeatedly entered system-update.target on boot. Because of a packaging issue, the tool that created the /system-update symlink could be installed without the service unit that was supposed to perform the upgrade (and remove the symlink). In fact, if there are no units in system-update.target, and /system-update symlink is created, systemd always "hangs" in system-update.target. This is confusing for users, because there's no feedback what is happening, and fixing this requires starting an emergency shell somehow, and also knowing that the symlink must be removed. We should be more resilient in this case, and remove the symlink automatically ourselves, if there are no upgrade service to handle it. This adds a service which is started after system-update.target is reached and the symlink still exists. It nukes the symlink and reboots the machine. It should subsequently boot into the default default.target. This is a more general fix for https://bugzilla.redhat.com/show_bug.cgi?id=1395686 (the packaging issue was already fixed). 2016-11-29 09:29:02 +03:00			`# This file is part of systemd.`
			`#`
			`# systemd is free software; you can redistribute it and/or modify it`
			`# under the terms of the GNU Lesser General Public License as published by`
			`# the Free Software Foundation; either version 2.1 of the License, or`
			`# (at your option) any later version.`

			`[Unit]`
			`Description=Remove the Offline System Updates symlink`
			`Documentation=man:systemd.special(5) man:systemd.offline-updates(7)`
			`After=system-update.target`
			`DefaultDependencies=no`
			`Conflicts=shutdown.target`
units: add missing Before=shutdown.target for units which it Conflicts There's a few services missing this ordering. Also remove a duplicate Conflicts=shutdown.target from systemd-volatile-root.service. 2017-09-25 14:10:38 +03:00			`Before=shutdown.target`
units: add system-update-cleanup.service to guard against offline-update loops Note: the name is "system-update-cleanup.service" rather than "system-update-done.service", because it should not run normally, and also because there's already "systemd-update-done.service", and having them named so similarly would be confusing. In https://bugzilla.redhat.com/show_bug.cgi?id=1395686 the system repeatedly entered system-update.target on boot. Because of a packaging issue, the tool that created the /system-update symlink could be installed without the service unit that was supposed to perform the upgrade (and remove the symlink). In fact, if there are no units in system-update.target, and /system-update symlink is created, systemd always "hangs" in system-update.target. This is confusing for users, because there's no feedback what is happening, and fixing this requires starting an emergency shell somehow, and also knowing that the symlink must be removed. We should be more resilient in this case, and remove the symlink automatically ourselves, if there are no upgrade service to handle it. This adds a service which is started after system-update.target is reached and the symlink still exists. It nukes the symlink and reboots the machine. It should subsequently boot into the default default.target. This is a more general fix for https://bugzilla.redhat.com/show_bug.cgi?id=1395686 (the packaging issue was already fixed). 2016-11-29 09:29:02 +03:00
			`# system-update-generator uses laccess("/system-update"), while a plain`
			`# ConditionPathExists=/system-update uses access("/system-update"), so`
			`# we need an alternate condition to cover the case of a dangling symlink.`
			`#`
			`# This service is only invoked if /system-update exists, i.e. if the`
			`# condition tested by system-update-generator remains true and the system`
			`# would be diverted into system-update.target again after reboot. This way`
			`# we guard against being diverted into system-update.target again, which`
			`# works as a safety measure, but we will not step on the toes of the`
			`# update script if it successfully removed the symlink and scheduled a`
			`# reboot or some other action on its own.`
			`ConditionPathExists=\|/system-update`
			`ConditionPathIsSymbolicLink=\|/system-update`

			`[Service]`
			`Type=oneshot`
			`ExecStart=/bin/rm -fv /system-update`
			`ExecStart=@SYSTEMCTL@ reboot`