for updating my servers and desktop PCs on Leap (15.6), Tumbleweed, Slowroll I use openSUSE/os-update: Update automatically package based OS and reboot if necessary since a while. Generally it does the job well. Updates are applied regularly and automatically. Good to know: all machines are turned off over night and for the weekends. So, automatic reboot is manually switched off because machines do boot once daily anyway.
But I have one issue with the desktop machines (not the server ones): sometimes (not always, just on some updates) my desktop (GUI) session is logged out with force. This is very annoying when explicitly working on something…
# Default entries, create /etc/os-update.conf with only the
# variables you want to override
#UPDATE_CMD=auto
UPDATE_CMD=dup
#REBOOT_CMD=auto
REBOOT_CMD=none
#RESTART_SERVICES=yes
#IGNORE_SERVICES_FROM_RESTART="dbus dbus-broker virtlockd"
#SERVICES_TRIGGERING_REBOOT=""
#SERVICES_TRIGGERING_SOFT_REBOOT="dbus dbus-broker"
And an additional /etc/systemd/system/os-update.timer.d/schedule.conf:
[Timer]
Persistent=true
(in order to force a daily update due to the standard systemd service settings of os-update — before it often missed the timer, in this way it is applied at least once daily, indeed)
Some idea of my own (details still may to get known…): is it maybe possible to modify the timer of systemd service for os-update in such a way, that the update service is triggered on shutting down the system?
The systems here are turned off over night and for the weekends anyway. So, an update a shutdown would not affect the business. And because they are shutdown AND booted regularly, the updates are applied quite regularly and within time (i.e. up to one day resp. tow/three days for the weekends).
But I personally don’t know how to implement such a timer.
Another way would be to leave the timer as it (plus my addition, see above). But to exclude some specific service(s) from restart. But which? I don’t know, yet.
By default, though, if the session ends, child processes end as well. It’s necessary to enable linger in the session using loginctl enable-linger <user> - though it seems you only have to do that once, as the setting appears to persist (a loginctl show-user <user> will show if linger is enabled, and having enabled it months ago, I see it is still set to yes.)