Updating using a systemd timer

I am running Leap 16.0 and I have changed the way that I use my system such that I no longer log in and update regularly.

I would like to update using a systemmd timer daily as I have a reboot timer also running daily and I figure that if I run an update before the reboot timer, any updates that need rebooting would be applied when the update timer is run.

I’m not that skilled in openSuSE, but what I am wondering is what command do I run in my timer file to perform the update. It has to be able to run unattended if that is possible.

Would someone kindly point me in the right direction of the command to run the update?

Thanks.

This seems like a reasonably good manual:

You need:
xxx.timer
xxx.service
and a script executed by the service.

Why a script?
Because of errors in your update???

Because I want it to run without my having to explicitly execute it. As I mentioned in my original post. I no longer log into my system regularly; therefore, “automatic” updates do not happen regularly.

1 Like

Thanks for your reply.

I’m already familiar with systemd timers as I mentioned in my original post.

What I need to know is do I run “zypper dup” or what?

Thanks for your reply.

Because I want the update to run without my having to explicitly execute it. As I mentioned in my original post. I no longer log into my system regularly; therefore, “automatic” updates do not happen regularly.

Do I run “zypper dup”?

Thanks again.

I think that transactional-update would deliver what you want. It is not officially supported, but how you’re intending to do it now isn’t either. The good thing about that is that it installs the updates in a future snapshot. When it has updated your running system remains untouched. When you reboot you boot into the update snapshot read/write.

1 Like

@wiyosaya If you not expecting any conflicts then an appropriate systemd service and timer to execute;

#!/usr/bin/bash
zypper --non-interactive up --auto-agree-with-licenses --download-only
zypper --non-interactive up --auto-agree-with-licenses
systemctl reboot

Check the output of zypper up --help for more options, or use the "rebootmgr " package…

1 Like

Recently, I have used https://software.opensuse.org/package/os-update resp. https://github.com/openSUSE/os-update/blob/main/README.md .

Currently, I use PackageKit-Offline-Update of https://software.opensuse.org/package/PackageKit resp. https://github.com/PackageKit/PackageKit/blob/main/README.md .

The latter one does strictly rely on reboots: it triggers an update for the next reboot and performs it on boot-up — not shutdown.

The first one performs updates online, during the system running. It can trigger (force) a reboot if you want. But you can leave that, if you want. Then, you have updates online (during system running)… and packages actually needing a reboot for their update need a reboot, of course.

Personally me, I used os-update without reboots, thus online only. Sometimes, it was crashing my desktop/system (not crashing in the way of deleting, but cancelling my desktop) due to larger updates or updates of desktop components. That’s way I moved to the PackageKit-Offline-Update (and I shutdown my system every night, so boot-up it every morning, any way).

1 Like

Thanks to everyone who replied.

This looks like what I am looking for. It sounds like using PackageKit may be the less problematic option for me.

I use this PC as a router/firewall/DNS, etc., so it is running all the time. I will have to look at the PackageKit docs to see if there is an equivalent Online update command to run because the PC is technically Online all the time except when it does its daily reboot.

Before I upgraded to Leap 16.0, I had uninstalled PackageKit due to the fact that I logged in fairly often and ran the former YaST2 “Online Update.” Now, I log in much less frequently and run myrlin, however, I’d rather the system update itself more frequently. For me, anyway, PackageKit sounds like the way to go. Its easy enough for me to reinstall it.

Thanks again for the info.

With the additional description I would suggest even stronger to go the transactional-update way. It would update into a new btrfs snapshot and reboot into that snapshot, hence keeping your system up-to-date continously

1 Like

Thanks for the suggestion, however, I’m running ext4 for my file system, not btrfs. To the best of my knowledge, that will not work with ext4.

No, it won’t. That said, given the use of the machine I would consider MicroOS which has btrfs, for a do-it-once and let-it-run future proof solution.

1 Like

Thanks for the suggestion.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.