Is it possible to check for updates after starting Linux only?

[DeN-AlB]

I love the new version 2 of arch-update. I want to check for updates after starting Linux only. I enabled arch-update-tray.service and arch-update.timer. Then I want to overwrite the properties of the timer service.

So I added the following into the override.conf:

[Timer]
OnStartupSec=15
OnUnitActiveSec=

I thought, that leaving the second entry empty would only check for updates after starting Linux. But when enabling the service now, I got the following error:

Failed to start arch-update.timer: Unit arch-update.timer has a bad unit file setting.

Isn't it possible to stop arch-update from checking for updates periodically?

[Antiz96]

I love the new version 2 of arch-update.

Hello,

Thanks for the kind words :)

I want to check for updates after starting Linux only. I enabled arch-update-tray.service and arch-update.timer. Then I want to overwrite the properties of the timer service.

So I added the following into the override.conf:

[Timer]
OnStartupSec=15
OnUnitActiveSec=

I thought, that leaving the second entry empty would only check for updates after starting Linux. But when enabling the service now, I got the following error:

Failed to start arch-update.timer: Unit arch-update.timer has a bad unit file setting.

Isn't it possible to stop arch-update from checking for updates periodically?

It is possible, the issue here is that you put OnStartupSec=15 in your override.conf, which is already declared in the arch-update.timer, creating a conflict.

Your override.conf should look like this:

systemctl --user edit arch-update.timer

[Timer]
OnUnitActiveSec=

[Antiz96]

I'm gonna add this example to the documentation in case other people also wants to check for update only after the startup of the system ;)

[DeN-AlB]

Thanks for the quick help.

It is possible, the issue here is that you put OnStartupSec=15 in your override.conf, which is already declared in the arch-update.timer, creating a conflict.

This doesn't work. My override.conf looks like this now:

[Timer]
OnUnitActiveSec=

Trying to start the service and the same message appears.

Failed to start arch-update.timer: Unit arch-update.timer has a bad unit file setting.
See user logs and 'systemctl --user status arch-update.timer' for details.

When I change the override.conf to somewhat like

[Timer]
OnUnitActiveSec=12h

all is fine. No error message appears. So it looks like that OnUnitActiveSec= mustn't be empty.

[Antiz96]

Hummm... You're right, my bad! I had the impression it was working but restarting the timer after that modification indeed triggers the "bad unit file" error :thinking:

I'm searching how to disable an existing parameter entirely with a simple override.conf but I can't find anything relevant... I'll continue searching for a bit but it may not be possible with a simple override.conf :shrug:

What you can do though is to run systemctl --user edit --full arch-update.timer which allows you to modify the whole timer unit (and not simply add/modify parameters from it such as an regular edit/override.conf is doing). From there you can just remove the OnUnitActiveSec=1h line. That will work for sure!

Make sure to delete your override.conf (and evetually run systemctl --user daemon-reload) before doing so to avoid conflicts.

[Antiz96]

After a second thought, the edit --full method feels easier & more straightforward than the "regular" edit/override.conf one (even if it might be a bit overkill for most cases).

I'm considering replacing the current documentation with that instead :thinking: The override.conf file method, with which you need to only declare the parameter you wanna change (twice actually, once to reset it and the second time to set a new value) feels unnecessarily complex compared to simply editing the actual content of the file with edit --full.

EDIT: Well, the advantage of using edit instead of edit --full is to not override the whole unit so, apart from the specific bit you changed, you still get other parameters from the "original" timer unit files (including eventual new additions/changes made to it in new releases). However, it has some limitations (e.g. the specific case you raised in that issue), it is definitely more complex (this repo had other opened issues in the past about how to make the override.conf work) and the arch-update.timer is not subject to change upstream wise so... maybe switching the documentation to edit --full is the right move :thinking:

[DeN-AlB]

Thanks a lot. I'll try that way. Let's see if it works. :+1:

[DeN-AlB]

It looks like it works. I only got a notification after starting the computer. Great!

Let's see what happens when an update of arch-update is released. :smile_cat:

[Antiz96]

It looks like it works. I only got a notification after starting the computer. Great!

You can actually check that it works by running systemctl --user list-timer:

You can see on my side that the timer will run again in 39min, while on your side this value should be blank (as it is not supposed to run again after the system booted).

Let's see what happens when an update of arch-update is released. 😸

systemctl edit --full created another file for the timer in your home directory that now supersedes the one shipped by Arch-Update so when a new version of arch-update is released, your own timer file should still be prioritized over the arch-update one :)

[Antiz96]

I only got a notification after starting the computer.

Just a quick precision about that specific point: Arch-Update is smart enough to not re-send notifications for the exact same list of available updates over and over. That means that, when starting your computer, if you have 2 pending updates available for "curl" and "htop" (for instance) and that one hour later you still only have 2 pending updates available for "curl" and "htop"; Arch-Update will not re-send a notification for it.

The check is performed at boot and then once an hour by default but a notification is only sent if the list of pending updates differs from the last check (in other words, only if there are new pending available updates compared to the last time).

You can actually force a check by running arch-update --check and you should not receive a notification if no new updates are available compared to the last check :)

[Antiz96]

Just a quick precision about that specific point: Arch-Update is smart enough to not re-send notifications for the exact same list of available updates over and over.

I guess I should add a precision about that in the documentation as well :)

[DeN-AlB]

You can actually check that it works by running systemctl --user list-timer:

Looks good so far.

[denalb@PROMETHEUS-ArchLinux ~]$ systemctl --user list-timers
NEXT LEFT LAST                              PASS
ED UNIT              ACTIVATES          
-       - Fri 2024-05-17 07:14:40 CEST 4h 3min ago arch-update.timer arch-update.service

1 timers listed.
Pass --all to see loaded but inactive timers, too.

when a new version of arch-update is released, your own timer file should still be prioritized over the arch-update one

Good to know! :smile:

The check is performed at boot and then once an hour by default but a notification is only sent if the list of pending updates differs from the last check (in other words, only if there are new pending available updates compared to the last time).

Also, good to know. :heart_eyes:

[Antiz96]

Looks good so far.

Thanks for the confirmation! :smile:

I'll add all of this to the documentation and close this issue afterwards :)

[DeN-AlB]

Again, thank you for the great support!

[Antiz96]

Me pleasure :)