[Finally SOLVED] Changing OnCalendar value of the updatedb.timer

berbae · 2014-04-18 09:29:24

The mlocate package enables the updatedb.timer by a link in /usr/lib/systemd/system/multi-user.target.wants to /usr/lib/systemd/system/updatedb.timer.
This is done by the package installation/update (so cannot be changed).
updatedb.timer :

[Unit]
Description=Daily locate database update

[Timer]
OnCalendar=daily
AccuracySec=12h
Persistent=true

'daily' in fact means at 00:00:00 each day, ie midnight.

So if the computer is shut down before midnight each day, and re-booted the next morning, I see that the updatedb.service is executed immediately during the boot, and takes ~30seconds; so it's not finished at the time of the user logging in.
The AccuracySec parameter (which should give a 00-12:00:00 interval to the timer) is ignored by the Persistent option.

I want to change that, by modifying the OnCalendar line to:

OnCalendar=12:00

which should mean each day at midday rather than midnight.

But I am not sure how to do that, without editing any files from the mlocate package.

Is creating my own modified updatedb.timer in /etc/systemd/system and
creating another link to it in /etc/systemd/system/multi-user.target.wants the way to go?

Can there be two links to two updatedb.timer files for the multi-user.target:
one in /usr/lib/systemd/system/multi-user.target.wants and
one in /etc/systemd/system/multi-user.target.wants ?

I am not sure if this is the right way to do this.

Last edited by berbae (2014-04-23 09:54:59)

karol · 2014-04-18 12:53:29

I'm not sure what exactly do you want.
Have you tried using e.g.

OnActiveSec=2m

to delay starting updatedb after you boot the system?
http://manned.org/systemd.timer.5

berbae · 2014-04-18 14:27:26

Thanks Karol
But if I change a file inside a package installed by pacman, it will be overwritten at the next update.
So I am looking for a way without touching any file in the package mlocate.

BTW can you confirm that the 'OnActiveSec' and the 'OnCalendar' parameters can be used simultaneously with the 'Persistent=true' option?

Stebalien · 2014-04-18 14:34:59

berbae wrote:

But if I change a file inside a package installed by pacman, it will be overwritten at the next update.
So I am looking for a way without touching any file in the package mlocate.

See the 11th paragraph of the DESCRIPTION section of systemd.unit(5).

berbae · 2014-04-18 15:09:48

Stebalien wrote:

See the 11th paragraph of the DESCRIPTION section of systemd.unit(5).

Along with a unit file foo.service, a directory foo.service.d/ may exist. All files with the suffix ".conf" from this
directory will be parsed after the file itself is parsed. This is useful to alter or add configuration settings to a unit,
without having to modify their unit files. Make sure that the file that is included has the appropriate section headers
before any directive.

Does this apply also to a foo.timer unit, because it says foo.service?

And can I place this 'updatedb.timer.d' directory in /etc/systemd/system/ rather than /usr/lib/systemd/system/ ?

Last edited by berbae (2014-04-18 15:19:21)

berbae · 2014-04-19 14:09:43

It works, following the paragraph cited above in 'man systemd.unit', on .timer files also.
With the addition of this file:

/etc/systemd/system/updatedb.timer.d/updatedb.timer.conf

[Timer]
OnCalendar=12:00

I prefered to work in /etc/systemd/system, because it is the place for local configurations;
that works as expected:

$ systemctl status updatedb.timer
* updatedb.timer - Daily locate database update
   Loaded: loaded (/usr/lib/systemd/system/updatedb.timer; static)
  Drop-In: /etc/systemd/system/updatedb.timer.d
           `-updatedb.timer.conf
   Active: active (waiting) since sam. 2014-04-19 10:57:37 CEST; 5h 16min ago

and in journalctl:

avril 19 12:00:13 arch64 systemd[1]: Starting Update locate database...
avril 19 12:00:25 arch64 systemd[1]: Started Update locate database.

Thanks Stebalien for pointing me to the solution.

Edit: I changed the name of the file to 'updatedb.timer.conf' to prevent confusion with '/etc/updatedb.conf'

Last edited by berbae (2014-04-19 21:13:19)

berbae · 2014-04-20 12:42:30

Unhappily this is [NOT SOLVED].
This morning, updatedb still started immediately during the boot, then it was started again at 12:00.
As my purpose is to prevent updatedb to run at boot time, this is not solved.

It is as if the drop-in conf file change of OnCalendar value is set only after the program has already started due to the Persistent option.

Persistent=
Takes a boolean argument. If true, the time when the service unit was last triggered is stored on disk. When the timer
is activated, the service unit is triggered immediately if it would have been triggered at least once during the time
when the timer was inactive.

The 'immediately' way seems to prevent using a drop-in conf file to change the OnCalendar value before the service is first triggered.
Maybe it is because I put the conf file in '/etc/systemd/system/updatedb.timer.d', I will try to move it to '/usr/lib/systemd/system/updatedb.timer.d'.
And will see tomorrow for the result.

Last edited by berbae (2014-04-20 14:25:55)

berbae · 2014-04-21 13:12:48

The move of the drop-in conf file to '/usr/lib/systemd/system/updatedb.timer.d' doesn't solve the problem either:

$ systemctl status updatedb.timer
* updatedb.timer - Daily locate database update
   Loaded: loaded (/usr/lib/systemd/system/updatedb.timer; static)
  Drop-In: /usr/lib/systemd/system/updatedb.timer.d
           `-updatedb.timer.conf
   Active: active (waiting) since lun. 2014-04-21 10:31:54 CEST; 1h 5min ago

avril 21 10:31:54 arch64 systemd[1]: Starting Daily locate database update.
avril 21 10:31:54 arch64 systemd[1]: Started Daily locate database update.

avril 21 10:31:55 arch64 systemd[1]: Starting Update locate database...
avril 21 10:32:31 arch64 systemd[1]: Started Update locate database.
avril 21 12:00:07 arch64 systemd[1]: Starting Update locate database...
avril 21 12:00:07 arch64 systemd[1]: Started Update locate database.

The 'Persistent' option seems to prevail on further changes made through drop-in conf files.
I think that any additions/changes made using drop-in conf files will be done after the 'Persistent' option causes the immediate triggering of the service unit of the timer (if it finds the original OnCalendar missed).

I now will come back to my first idea (in the OP) to try to solve that issue:

# cd /usr/lib/systemd/system
# cp updatedb.timer /etc/systemd/system
# cd /etc/systemd/system
# vim updatedb.timer 
# cat updatedb.timer
[Unit]
Description=Daily locate database update

[Timer]
OnCalendar=12:00
AccuracySec=12h
Persistent=true
# cd multi-user.target.wants
# ln -s ../updatedb.timer
# systemctl daemon-reload
# systemctl status updatedb.timer
* updatedb.timer - Daily locate database update
   Loaded: loaded (/etc/systemd/system/updatedb.timer; enabled)
   Active: active (waiting) since lun. 2014-04-21 10:31:54 CEST; 4h 28min ago
...

This is based on the prevalence of '/etc/systemd/system' vs '/usr/lib/systemd/system' when units of the same name are found.
I will see tomorrow if updatedb will stop running during boot and will wait till 12:00 to be launched.

Edit: I forgot to say that I removed the drop-in conf files before doing this of course.

Last edited by berbae (2014-04-23 09:54:11)

berbae · 2014-04-22 21:40:38

The method in my previous post reaches the target:

$ journalctl -b|grep database 
avril 22 09:46:42 arch64 systemd[1]: Starting Daily locate database update.
avril 22 09:46:42 arch64 systemd[1]: Started Daily locate database update.
avril 22 12:00:23 arch64 systemd[1]: Starting Update locate database...
avril 22 12:00:36 arch64 systemd[1]: Started Update locate database.

The modified updatedb.timer unit from /etc/systemd/system is started at boot, but the updatedb.service unit is triggered at 12.00 as expected.

So this is a solution to choose the OnCalendar value, and so to prevent the service from running during boot.

I think that the Persistent option should be able to delay the triggering of a missed timer, rather than doing that immediately during boot.
I think also that 'OnCalendar=daily' should mean within the last 24 hours rather than at midnight only.

Of course changing the OnCalendar value directly in the updatedb.timer installed by the package is easier;
or re-building the mlocate package from the ABS, after a change of the OnCalendar value.
But this will require to repeat it at every update of the mlocate package (though no so frequent).
Nevertheless there exists a way to obtain the same, without modifying the installed mlocate package.

Last edited by berbae (2014-04-22 21:46:40)

smudge · 2014-04-25 01:01:11

You could try editing /etc/systemd/system/updatedb.timer.d/updatedb.timer.conf to look like:

[Timer]
OnCalendar=
OnCalendar=12:00

Some settings need to be reset before being replaced although that doesn't seem to apply to Description= fields.

berbae · 2014-04-25 09:10:52

Thanks Smudge
But I don't use the drop-in conf files method anymore, in this case at least, because the Persistent option in the timer operates before it applies the changes made in the conf files.

smudge · 2014-04-27 00:02:56

Ah, I didn't read the previous posts well enough. Why not try setting Persistent=false:

$ cat /etc/systemd/system/updatedb.timer.d/updatedb.timer.conf
[Timer]
OnCalendar=
OnCalendar=12:00
Persistent=false

I've only briefly tested this but I think it's working.

Raynman · 2014-04-27 08:54:17

berbae wrote:

Thanks Smudge
But I don't use the drop-in conf files method anymore, in this case at least, because the Persistent option in the timer operates before it applies the changes made in the conf files.

No, I think smudge is right. Your drop-in conf file adds a second timer, so you're telling it to run updatedb twice a day, at 0:00 and at 12:00. If you then shut down the computer somewhere between 12:00 and 0:00, and reboot the next day between 0:00 and 12:00, the 0:00 hasn't fired yet so it will (due to Persistent=True) start immediately.

If you clear the OnCalendar= setting first (assuming this works as expected), the new 12:00 calendar event will be the only trigger and you can leave Persistent=true in case the computer isn't running at 12:00. You could also not reset the OnCalendar setting and instead add the new 12:00 time combined with Persistent=false. Then you might miss an update, but if the computer is always running around 12:00 and never around 0:00, it should be triggered only at midday. And of course other variations are then also possible.

Arch Linux

#1 2014-04-18 09:29:24

[Finally SOLVED] Changing OnCalendar value of the updatedb.timer

#2 2014-04-18 12:53:29

Re: [Finally SOLVED] Changing OnCalendar value of the updatedb.timer

#3 2014-04-18 14:27:26

Re: [Finally SOLVED] Changing OnCalendar value of the updatedb.timer

#4 2014-04-18 14:34:59

Re: [Finally SOLVED] Changing OnCalendar value of the updatedb.timer

#5 2014-04-18 15:09:48

Re: [Finally SOLVED] Changing OnCalendar value of the updatedb.timer

#6 2014-04-19 14:09:43

Re: [Finally SOLVED] Changing OnCalendar value of the updatedb.timer

#7 2014-04-20 12:42:30

Re: [Finally SOLVED] Changing OnCalendar value of the updatedb.timer

#8 2014-04-21 13:12:48

Re: [Finally SOLVED] Changing OnCalendar value of the updatedb.timer

#9 2014-04-22 21:40:38

Re: [Finally SOLVED] Changing OnCalendar value of the updatedb.timer

#10 2014-04-25 01:01:11

Re: [Finally SOLVED] Changing OnCalendar value of the updatedb.timer

#11 2014-04-25 09:10:52

Re: [Finally SOLVED] Changing OnCalendar value of the updatedb.timer

#12 2014-04-27 00:02:56

Re: [Finally SOLVED] Changing OnCalendar value of the updatedb.timer

#13 2014-04-27 08:54:17

Re: [Finally SOLVED] Changing OnCalendar value of the updatedb.timer

Board footer