Any cons against anacron/fcron instead of cron?

uxer

OpenBSD laptop which is on in daytime only.
When I try to locate something, it responds:

locate: database too small: /var/db/locate.database

I assume that /etc/weekly — which is meant to update the locate database — has never been run by cron as the laptop is off when the cron is meant to launch /etc/weekly. I assume that maintenance meant to be being done via scripts /etc/daily, /etc/weekly, /etc/monthly, /etc/daily.local, /etc/weekly.local, /etc/monthly.local is unlikely to be ever triggered.

http://man.openbsd.org/weekly#CAVEATS says:

If the host machine is not running 24/7, these scripts may never be run. Adjusting the time fields in the system crontab(5) may partially alleviate this problem.

Yet anacron/fcron promise more flexible and elegant solution. But are there any drawbacks?

At the very least,
anacron Last Update: 2009-07-16 according to https://sourceforge.net/projects/anacron/
fcron is not packaged for and even ported to OpenBSD.

But maybe there are more arguments against anacron/fcron in favor of adjusting time in cron?

uxer I wouldn't trust something that hasn't been updated in over 10 years.

rvp

uxer Adjust the time fields in the crontab as the man-page recommends. Or, just run the scripts as root whenever.

JuvenalUrbino

uxer you may have a look at remind

uxer

pin I can't say about anacron specifically, but if a program has been well-designed and well-coded and doesn't deal with changing environment, then its age may mean nothing.
Correct me if I'm wrong

uxer

JuvenalUrbino remind is a capable software,
but by skimming through its manpage I didn't notice an easy way of performing esp. weekly and monthly properly and reliably. I haven't dug into it, but I believe with remind's scripting capabilities one can solve the task, albeit you need to learn another tool for it. I may have skimmed the manpage too quickly, I acknowledge.
Or maybe throw a link at me with the code 😉

Anyway, thank you for mentioning remind, I'll give it a shot for reminders

uxer

In my imaginary perfect world, fcron would be in the base install.
But neither it is packaged, nor ported, nor does it compile. I tried 2 last stable and 2 last dev releases.

socket.c:312:49: error: use of undeclared identifier 'SO_PASSCRED'
    setsockopt(client->fcl_sock_fd, SOL_SOCKET, SO_PASSCRED, &true,
                                                ^

fcrondyn_svr.c:268:49: error: use of undeclared identifier 'SO_PASSCRED'
    setsockopt(client->fcl_sock_fd, SOL_SOCKET, SO_PASSCRED, &true,
                                                ^

The same with --with-fcrondyn=no
I have not found a tutorial on installing fcron on OpenBSD and my c-ignorance prevents me from troubleshooting.

For a while, I was brewing some helper script(s) in my mind that would wrap the daily-weekly-monthly and it even seemed not-that-hard (it always seems not-that-hard before you have started implementing it) but upon reading anacron's manpage I noticed it does exactly how I imagined my script(s) but is more elaborate (mostly) and probably more debugged.
There is also a vdcron of fcron&anacron ilk - a ksh script by an OpenBSD user.
Dunno, it is in Beta whereas anacron is 2.5.3p4 and both are not updated.

Let me try it with `anacron`.

/etc/anacrontab:

# `SHELL`, `PATH` & `HOME` from `/usr/local/share/doc/pkg-readmes/anacron`
# same values as in `crontab`
SHELL=/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin
HOME=/var/log

# have these a due effect for OpenBSD's anacron port? Need to check
RANDOM_DELAY=0
START_HOURS_RANGE=0-23
MAILTO=root
MAILFROM=anacron

# `@daily`, `@weekly` & `@monthly` period macros are not supported by OpenBSD's anacron port

#period  #delay  #job-ID     #command
 1       0       id_daily    nice -n 10 /bin/sh /etc/daily
 7       0       id_weekly   nice -n 10 /bin/sh /etc/weekly
30       0       id_monthly  nice -n 10 /bin/sh /etc/monthly

Raf Czlonka https://marc.info/?l=openbsd-bugs&m=164442189125530&w=2 :

anacrontab(5) from this port doesn't supports @-strings known from crontab(5) or 3rd-party updates to anacron(8).

Now, anacron is not a daemon and needs to be launched periodically. I want it to be run when I start using the laptop i.e. on booting up and resume after suspend/hibernate; and for the case that I nevertheless leave the laptop running 24/7, run anacron during the night.

Run on booting and during the night via root's crontab:
# crontab -e:

#minute hour    mday    month   wday    [flags] command

# don't do daily/weekly/monthly maintenance from crontab directly
# 30    1       *       *       *       /bin/sh /etc/daily
# 30    3       *       *       6       /bin/sh /etc/weekly
# 30    5       1       *       *       /bin/sh /etc/monthly

# do daily/weekly/monthly maintenance via anacron on booting up
@reboot                                 [ "$(apm -av)" = 'A/C adapter state: connected' ] && /usr/local/sbin/anacron -ds

# do daily/weekly/monthly maintenance via anacron during the night in case of 24/7 operation
30      1       *       *       *       [ "$(apm -av)" = 'A/C adapter state: connected' ] && /usr/local/sbin/anacron -ds

The [ "$(apm -av)" = 'A/C adapter state: connected' ] && part is meant to spare the battery life by running tasks only if A/C is plugged. Beware of never-performed maintenace if you switch on your laptop always on battery and charge it after it has booted/resumed or while it is off and if you happen to be on battery at the specified nighttime.

Full path /usr/local/sbin/anacron here since:

Raf Czlonka https://marc.info/?l=openbsd-bugs&m=164442189125530&w=2 :

root's PATH does contain /usr/local/sbin, however...

# crontab -l
PATH=/bin:/sbin:/usr/bin:/usr/sbin

... crontab's PATH, does not.
You'll either have to use the full path /usr/local/sbin/anacron or adjust PATH accordingly.

-d option is recommended in /usr/local/share/doc/pkg-readmes/anacron

Run on resume:
/etc/apm/resume:

#! /bin/sh

{ [ "$(apm -av)" = 'A/C adapter state: connected' ] && anacron -s ;} &

You need to run in background with {;} & since without it:

Theo de Raadt https://marc.info/?l=openbsd-bugs&m=164531776906220&w=2 :

apmd runs the script, and does nothing until the script is finished.
The script runs apm.
apm talks to apmd.
apmd is not listening, it is busy waiting for the script to finish.
Once you understand the mechanism you'll realize it will never work.

With {;} & we let the /etc/apm/resume script finish and free apmd so that it can respond to our apm -av

/etc/apm/* must be executable, so # chmod +x /etc/apm/resume

/etc/apm/* are not picked up automatically upon creation/edit, so:
# rcctl restart apmd

http://man.openbsd.org/apmd :

The resume program is run after resuming from a stand-by or suspended state.

Does this mean it isn't run after hibernate? Need to check.

This config has been only partially tested yet