Hi pavinjoseph,
I had a look at os-update and this seems to be what I want. Wonder why others don’t use it?
I have set it up with basic config as issued but changed UPDATE_CMD to dup.
It seems the timer works daily on a random basis with 2 hour variation. Is that right. will see how it goes with this.
Meanwhile I would like to understand why your simple suggestion didn’t work but not really necessary so only if you have time.
Many thanks,
Regards,
Budgie2
The unit as you posted it will run long before network is up. Whatever this command shows is irrelevant, as this command will be invoked after network is already configured.
Apr 12 16:28:40 HP-Z640-1 systemd[1]: /etc/systemd/system/dup.service:15: Unknown section ‘Timer’. Ignoring.
From the logs, it seems the two files (service and timer) was created as a single file?
Not sure where the Timer section is coming from otherwise.
Anyway this appears to be the problem.
It’s actually two files, a service without an Install section and a timer.
The service file is activated by the timer on an already online system. There’s no auto-resume or other magic going on here!
Yes, sorry, I misread it.
OK, and thanks for the discussion. I have taken pavinjoseph’s hint here and looked at os-service. Seems like it does the job so have set it up and it seems OK and ready to roll:-
alastair@HP-Z640-1:~> systemctl status os-update.timer
● os-update.timer - Update of system timer
Loaded: loaded (/usr/lib/systemd/system/os-update.timer; enabled; preset: disabled)
Active: active (waiting) since Mon 2024-04-15 10:47:30 BST; 9min ago
Trigger: Tue 2024-04-16 01:08:18 BST; 14h left
Triggers: ● os-update.service
alastair@HP-Z640-1:~>
No journalctl entry yet as it has never run and will not until tonight.
Regarding the original suggestion I am not sure why this didn’t work. Should I persevere with this? Less point now but good to understand a bit more which may hopefully help me learn!!!
The original suggestion was to create two files, a service and its corresponding timer.
I guess you might’ve added it as a single service file:
# /etc/systemd/system/dup.service
[Unit]
Description=Distribution upgrade
[Service]
Type=oneshot
ExecStartPre=/usr/bin/flatpak update --noninteractive
ExecStartPre=/usr/bin/zypper --non-interactive --no-cd refresh
ExecStart=/usr/bin/zypper --non-interactive --no-cd dist-upgrade --auto-agree-with-licenses
# THE SERVICE FILE ENDS HERE
# ===================================================
# THE TIMER FILE STARTS HERE
# /etc/systemd/system/dup.timer
[Unit]
Description=Distribution upgrade
[Timer]
Unit=bkupd.service
OnCalendar=*-*-* 03:00:00
[Install]
WantedBy=timers.target
To avoid such issues in the future, verify the service file by:
systemd-analyze verify /etc/systemd/system/dup.service
Makes sense but I was too thick to appreciate it.
I see that the os-update app also uses two services but what is not clear is why they are installed thus:-
/usr/libexec/os‐update
/usr/lib/systemd/system/os‐update.service
/usr/lib/systemd/system/os‐update.timer
Why are these in usr/lib… and not in /etc/systemd/…?
Another question, although at present I do not use flatpacks I may in future. Would these be updated by zypper dup ? Also I note you have included two ExecStartPre= lines.
Why update flatpack first?
The refresh line seems to be good practice but I cannot see this included in the /usr/libexec/os‐update script. Any views?
Further to this and your suggested service, I have corrected my error and now have another question:-
alastair@HP-Z640-1:~> systemd-analyze verify /etc/systemd/system/dup.service
/usr/lib/systemd/system/plymouth-start.service:15: Unit uses KillMode=none. This is unsafe, as it disables systemd's process lifecycle management for the service. Please update the service to use a safer KillMode=, such as 'mixed' or 'control-group'. Support for KillMode=none is deprecated and will eventually be removed.
alastair@HP-Z640-1:~>
Now I am lost!
Hey, I wasn’t getting notified of your replies as the reply was made against the general thread and not to my response! 
Systemd timers (like a powerful cronjob) have an associated service file which the timer runs at the predefined time: systemd.timer
The default configs shipped by the package maintainers will be in /usr/etc or /usr/lib. User/admin changes should be made to /etc/ as changes to the former two will be wiped after a package update. You can use the /usr/.. configs as template for your own /etc.. configs.
Zypper won’t update flatpaks, at least not without a plugin which I’m not sure exists.
This is just what I ended up doing because zypper dups are prone to failure, you can also perform the flatpak update last by using the ExecStartPost directive. systemd.service
This is redundant and probably would lead to issues as you have both os-update and this systemd service/timer installed. Remove /etc/systemd/system/dup.service and /etc/systemd/system/dup.timer and use os-update.
I do not recommend using the trimmed version of dup.service I posted earlier as there are two issues with it:
- Unlike the full version it does not perform backup and more importantly does not perform a safe dup using
atomic-update - It does not provide a failure notification like
os-update.
Hi and many thanks for getting back to me.
Since I had downloaded os-update and had yet to edit my earlier errors with your earlier suggestion I had disabled them and left os-update set up to run. I did not have both approaches running and I note your caveat about your trimmed down version. I still know nothing about atomic-update!
Moving on I couldn’t be sure if my os-update had run because the run last night is not shown, only the next run:-
alastair@HP-Z640-1:~> systemctl list-timers --all | grep os-update.timer
Wed 2024-04-17 01:26:07 BST 8h - - os-update.timer os-update.service
alastair@HP-Z640-1:~>
I had a look at the log:-
alastair@HP-Z640-1:~> sudo journalctl -u os-update.service
[sudo] password for root:
Apr 16 01:35:59 HP-Z640-1 systemd[1]: Starting Update of system...
Apr 16 01:36:01 HP-Z640-1 os-update[30459]: Loading repository data...
Apr 16 01:36:01 HP-Z640-1 os-update[30459]: Reading installed packages...
Apr 16 01:36:02 HP-Z640-1 os-update[30459]: Warning: You are about to do a distribution upgrade with all enabled repositories. Make>
Apr 16 01:36:02 HP-Z640-1 os-update[30459]: Computing distribution upgrade...
Apr 16 01:36:02 HP-Z640-1 os-update[30459]: The following 6 items are locked and will not be changed by any action:
Apr 16 01:36:02 HP-Z640-1 os-update[30459]: Available:....
.......
Apr 16 01:41:17 HP-Z640-1 os-update[30458]: Update was successful
Apr 16 01:41:17 HP-Z640-1 os-update[30458]: Reexecing systemd
Apr 16 01:41:22 HP-Z640-1 os-update[30458]: Restarting cron
Apr 16 01:41:22 HP-Z640-1 os-update[30458]: Restarting cups
Apr 16 01:41:22 HP-Z640-1 os-update[30458]: Restarting sshd
Apr 16 01:41:22 HP-Z640-1 os-update[30458]: Restarting systemd-journald
Apr 16 01:41:22 HP-Z640-1 os-update[30458]: Restarting systemd-logind
Apr 16 01:41:22 HP-Z640-1 os-update[5105]: Restarting systemd-logind
Apr 16 01:41:22 HP-Z640-1 os-update[30458]: Restarting systemd-machined
Apr 16 01:41:22 HP-Z640-1 os-update[5149]: Restarting systemd-machined
Apr 16 01:41:22 HP-Z640-1 os-update[30458]: Restarting systemd-udevd
Apr 16 01:41:22 HP-Z640-1 os-update[5170]: Restarting systemd-udevd
Apr 16 01:41:22 HP-Z640-1 os-update[5175]: Since the last system boot core libraries or services have been updated.
Apr 16 01:41:22 HP-Z640-1 os-update[5175]: Reboot is suggested to ensure that your system benefits from these updates.
Apr 16 01:41:22 HP-Z640-1 os-update[30458]: Update suggests reboot
Apr 16 01:41:22 HP-Z640-1 os-update[30458]: Trigger reboot with systemctl reboot
Apr 16 01:41:22 HP-Z640-1 os-update[5179]: Trigger reboot with systemctl reboot
Apr 16 01:41:22 HP-Z640-1 systemd[1]: os-update.service: Deactivated successfully.
Apr 16 01:41:22 HP-Z640-1 systemd[1]: Stopped Update of system.
Apr 16 01:41:22 HP-Z640-1 systemd[1]: os-update.service: Consumed 1min 58.991s CPU time.
alastair@HP-Z640-1:~>
So it ran OK but am not sure if the re-boot actually took place as it is not clear to me from the line
Trigger reboot with systemctl reboot
whether this executes the command or if I have made a mistake with the configuration.
Any further advice?
It’s possible to see when the service was last run from the journal logs or simply by doing:
systemctl status os-update.service
To check if the system rebooted correctly, check the last boot time:
who -b
last | grep boot | head
Hi and thanks again. I am pleased to report that all is working rather well. Much as I had dared hope so very many thanks. I hope this also helps others with similar aims.
Regards,
Budgie2
1 Like
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.