Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#41688 - [mlocate] updatedb.timer induced HDD thrashing on bootup

Attached to Project: Arch Linux
Opened by Hermann Zahnweh (eigengrau) - Monday, 25 August 2014, 08:02 GMT
Last edited by Gaetan Bisson (vesath) - Sunday, 14 December 2014, 17:56 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Thomas Bächler (brain0)
Gaetan Bisson (vesath)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No



updatedb.timer currently causes severe thrashing and bootup delays due
to it triggering immediately after boot, in parallel with all other
timer units. For the time being, until systemd.timers gain (proper)
support for a random delay or spread, we should look for work-arounds,
such as using a non-persistent trigger or an OnBootSec= trigger.

On the mailing list, Thomas reported that timer activation would be
randomized due to TimerSlackNSec=. I thought so too and suspected a
bug first, but studying the man page reveals that TimerSlackNSec= is
actually not designed in that way. Rather, TimerSlackNSec= is meant to
bunch all timers together, if possible, in order to minimize
interrupts, and it does not claim that the trigger time will be truly
random. So the current behavior (updatedb/mandb timers triggering
immediately after boot in parallel), is due to design, and #systemd
confirmed that indeed TimerSlackNSec= is not meant for randomization.

I have filed an enhancement request on the systemd bug tracker.
Possibly some folks could chime in there if they would find that
feature useful, to give it some more traction.

There might not be a good workaround available (personally, for me
OnBootSec= works, but for others the one-time daily thrashing might be
preferable). In case no good ideas come up, this task can be kept as a
todo until systemd has a timer delay feature.

Additional info:
* mlocate 0.26-3
This task depends upon

Closed by  Gaetan Bisson (vesath)
Sunday, 14 December 2014, 17:56 GMT
Reason for closing:  Fixed
Additional comments about closing:  mlocate-0.26-5 in [testing]
Comment by Gaetan Bisson (vesath) - Tuesday, 26 August 2014, 01:53 GMT
One thing I would fine sensible is to follow the example of systemd-tmpfiles-clean.timer which is provided by systemd itself. It uses OnBootSec=15min and OnUnitActiveSec=1d (instead of OnCalendar and such).

Thomas, you know much more about systemd than me; could you have a look at what I commited to SVN and revert it if that does not make sense to you? (Note that I also changed the IO scheduling settings.)
Comment by Thomas Bächler (brain0) - Sunday, 14 December 2014, 16:20 GMT
I am sorry for not responding earlier, I did not see this report until it got closed yesterday.

The suggested (and implemented) solution makes no sense at all. It runs the updatedb.service on every boot, even if I boot 100 times a day. This is NOT desired behaviour. For systems that are not "always-on", the OnUnitActiveSec setting does not work as expected either.

The initial problems does not exist any longer anyway. IIRC, timers are now delayed until bootup has finished, solving the bootup delays. As for running all timers at the same time, I don't see your "solution" doing anything about that. And I don't see a problem with that. Setting proper IO scheduling options is the right way to handle this, the kernel is able to ensure that there are no problems.
Comment by Gaetan Bisson (vesath) - Sunday, 14 December 2014, 17:56 GMT
Thanks for your input.