locate: Use systemd timer instead of cron

[wmertens]

This way, it will run 24 hours after the last run finished.

Breaking API: the services.locate.period option is replaced by
services.locate.hours.

[edolstra]

+1 on using systemd timers, but I'm not sure running 24h after the last run is a good idea. People typically want to run updatedb when the system is unlikely to be in use (i.e. at night).

[wmertens]

Myeah... on the other hand, my laptop and I'm guessing most computers are typically in standby at night.
I'll make it accept both fixed and relative times, and I'm also looking at mlocate which is more efficent.

In general we may want to have a service like Mac's Power Nap/Intel's Rapid Connect which does maintenance during sleep periods. I wonder how we'd configure such a thing so it automatically runs only the needed services.

[vcunat]

Any progress?

BTW, automatically doing maintenance during sleep periods sounds really tricky. It certainly won't be for everyone, e.g. I'm sleeping next to my computer ;-)

[wmertens]

Work was a bit hectic, I'll look at this again soon.
The Power Nap thing is really for very silent laptops I'd say... I never noticed my MacBook Air doing it and yet it did fetch mail during those wakeup periods.

[Fuuzetsu]

-1 on ‘every set period’, using cron is far more versatile. Maybe we want to run every Wednesday, Thursday and Friday evening only or something. This is important in presence of network shares, varying sleep patterns and whatever else.

[edolstra]

What do you mean with cron being more versatile? Systemd timers allow you to specify something like Wed,Thu,Fri 19:00:00.

[Fuuzetsu]

Oh, OK, I misunderstood then, I thought that using systemd timers would no longer allow us for such customisation level.

[7c6f434c]

Do I understand it right that the PR as it stands would lose this versatility?

Should we close this instance so when a systemd-timer-based implementation of full functionality appears, it would be a new PR?

[vcunat]

No, I understood the discussion in the way that we know of no case where the versatility would be lost.

[7c6f434c]

No, I understood the discussion in the way that we know of no case where the versatility would be lost.

This specific implementation sets just period in hours.

[vcunat]

Ah, I didn't notice. Then, the PR should be updated to use the general systemd specifier, I guess.

[7c6f434c]

@wmertens would you allow arbitrary SystemD timer specifications in the service?

[aristidb]

So do we want to do this or not?

[vcunat]

My understanding: this implementation would lose some versatility, so it should be changed (systemd itself reportedly allows enough versatility).

[wmertens]

I will address this shortly.

Wout.
On Sep 16, 2014 8:45 PM, "Vladimír Čunát" notifications@github.com wrote:

My understanding: this implementation would lose some versatility, so it
should be changed (systemd itself reportedly allows enough versatility).

—
Reply to this email directly or view it on GitHub
#2758 (comment).

[aristidb]

I propose just opening a new pull request if there is a concrete new implementation.