This post is part question and part bug report. The bug is that the PureOS store on my Librem 5 doesn’t provide an obvious way to change what time it checks for updates. The question is: how can I change what time it checks for updates?
Due the hours I now work, the default of checking at about 06:30 is completely useless. It is guaranteed that the phone will not be on WiFi and probably not even powered up at 06:30. It’s also more than likely that the next time I switch it on, it will be away from WiFi. This effectively means the automatic check for updates is broken, unless I can cause it to check at a more appropriate time.
I would like the phone to check for updates earlier in the morning.
(I’m not going to use 4G to check for updates: I pay £0.01 per MB for 4G data.)
I suppose the “proper” fix for the bug would be to adjust the timing of the update check automatically, according to when the phone is most likely to be switched on and connected to WiFi, based on usage patterns over time and weighted towards the more recent history.
I tried editing the systemd timers apt-daily.timer and apt-daily-upgrade.timer, as described in this Unix & Linux StackExchange answer. However, this seems to have made no difference. The phone is still checking for updates at about 06:30.
I assume that PureOS Store’s update checks are based on some other mechanism. Does anyone know the name of that mechanism (for teh web searchery), or how to configure it?
I’ve just this moment tried changing what time my cron.daily, cron.weekly and cron.monthly scripts run, based on this advice for Ubuntu, combined with the wild assumption that the same mechanism might be at play in PureOS. However, I will have to wait to find out whether it has the desired effect.
Did you reload after making the change to the .timer file?
Perhaps the real answer is to take matters into your own hands. Just start PureOS Store and touch the Updates tab and touch the check button (top left). If there are updates available then touch to Download and Restart to install …
Do that when it suits you.
Yeah nah. Maybe for you but a lot of people prefer things not to happen at seemingly random, out-of-their-control times. Also, some repos prefer randomised client times so that they don’t get a sudden surge of network load.
It may make sense to give you control to suppress automatic package downloads entirely when not on WiFi. Perhaps see whether Apt offers such a setting.
Reload what? In any case, I am generally switching my phone off and on again at least once per day at the moment. (No point in leaving it turned on wasting battery when am not available to use it.)
Of course I am aware of this obvious feature. But I want it to download the updates automatically, so I don’t have to sit there waiting for my internet connection. Then, I can choose to install the updates (or not) at my leisure. (That is what happens if I leave the phone switched on and connected to WiFi during the magic moment near 06:30.)
Conscious that this is a Gnome thing, and Gnome people like to avoid adding new settings if at all possible, I felt inclined to suggest something that I thought was Gnomey. This doesn’t mean I necessarily think it’s the best solution. Personally I would just add a setting to specify the time. I realise in hindsight that my thought process was not necessarily apparent from the way I wrote this. Either way, there would be an element of randomness, as indeed there seems to be with the current default time to check for updates.
This is already the default behaviour. My mention of not wanting to check for updates over 4G was merely in anticipation that people might suggest that I should enable updates over 4G as a workaround for not being able to change the time of the update check.
I would have thought I’d already effectively modified this by running systemctl edit on the timers, as mentioned in my first post. However, I will try editing these files directly and see if that makes a difference.
Changing what time cron.daily, cron.weekly and cron.monthly run does not seem to have made any difference.
If you edit the systemd configuration with vi or any other similar editor then afterwards you need to do
systemctl daemon-reload
to make the change effective. However, according to the man page, if you use systemctl edit ... then the reload is automatic.
To be honest, I’m not experiencing the problem that you have. My daily upgrade timer config says ‘6:00’ and randomized delay of 60m but the phone would often not be booted before 7:00 (like you?, the poor time-between-charges means that the phone spends overnight every night powered off). However the log shows that upgrades are happening (not too long after power up). So …
On the other hand, apt-daily.timer says ‘6,18:00’ and randomized delay of 12h - which means that most of the time apt will get to run. (The effect of that should be that it checks twice every 24 hours at an uncorrelated pair of times - and for me there’s a good chance that one of those will be missed due to being powered off, so the result will mostly be one check every 24 hours.)
So what does yourapt-daily.timer file say?
I would think that in addition to setting the start time, you will need to squeeze down the randomness interval. The more predictable you are about when the phone will be up, the narrower you can squeeze that interval. It probably doesn’t matter if on occasional days, you miss the update.
I think the updates are checked for at the specified time, or the next time the phone is booted. However, I have the additional constraint that the next time I boot the phone it is usually not connected to WiFi. The scheduled check is “used up” determining that there is no WiFi, and then it does not check again. At least, that’s my theory. You’re probably fine as long as it’s online when you boot it.
I haven’t got time to check the files right now. the systemctl edit commend doesn’t actually edit those files, instead it creates another file that overrides it. But, I’ll report back when I have more time.
I’ve noticed that the update check now seems to be occurring the next time the phone has an internet connection, rather than at next boot. This is obviously much better and largely solves the problem. It doesn’t cover the case where I wish to apply the updates first thing in the morning when I pick up the phone, but to be honest that’s not as important to me as I previously felt it was.