Instead of the first five fields, one of eight special strings may appear:
string meaning @reboot Run once, at startup.
Me: Hmm, I wonder if that actually works:
% crontab -l
@reboot echo REBOOT
crond:
Cron Daemon Cron <root> echo REBOOT 8:46:54 AM
Cron Daemon Cron <root> echo REBOOT 8:47:24 AM
Cron Daemon Cron <root> echo REBOOT 8:48:35 AM
Cron Daemon Cron <root> echo REBOOT 8:48:37 AM
Cron Daemon Cron <root> echo REBOOT 8:48:48 AM
Cron Daemon Cron <root> echo REBOOT 8:48:58 AM
Cron Daemon Cron <root> echo REBOOT 8:49:59 AM
Cron Daemon Cron <root> echo REBOOT 8:49:59 AM
Cron Daemon Cron <root> echo REBOOT 8:49:59 AM
Cron Daemon Cron <root> echo REBOOT 8:50:20 AM
Cron Daemon Cron <root> echo REBOOT 8:50:31 AM
Cron Daemon Cron <root> echo REBOOT 8:54:06 AM
Cron Daemon Cron <root> echo REBOOT 8:54:06 AM
Cron Daemon Cron <root> echo REBOOT 8:54:06 AM
Cron Daemon Cron <root> echo REBOOT 8:54:06 AM
Cron Daemon Cron <root> echo REBOOT 8:54:26 AM
Cron Daemon Cron <root> echo REBOOT 8:54:39 AM
Cron Daemon Cron <root> echo REBOOT 8:55:22 AM
Cron Daemon Cron <root> echo REBOOT 8:56:11 AM
Cron Daemon Cron <root> echo REBOOT 8:56:50 AM
Cron Daemon Cron <root> echo REBOOT 8:57:46 AM
Cron Daemon Cron <root> echo REBOOT 8:58:32 AM
Cron Daemon Cron <root> echo REBOOT 8:59:16 AM
Cron Daemon Cron <root> echo REBOOT 9:00:03 AM
Cron Daemon Cron <root> echo REBOOT 9:00:55 AM
Cron Daemon Cron <root> echo REBOOT 9:02:03 AM
Cron Daemon Cron <root> echo REBOOT 9:02:42 AM
Cron Daemon Cron <root> echo REBOOT 9:03:35 AM
Cron Daemon Cron <root> echo REBOOT 9:04:27 AM
Cron Daemon Cron <root> echo REBOOT 9:05:13 AM
Cron Daemon Cron <root> echo REBOOT 9:06:05 AM
Cron Daemon Cron <root> echo REBOOT 9:06:48 AM
Cron Daemon Cron <root> echo REBOOT 9:07:35 AM
Cron Daemon Cron <root> echo REBOOT 9:08:23 AM
Cron Daemon Cron <root> echo REBOOT 9:09:07 AM
Cron Daemon Cron <root> echo REBOOT 9:09:52 AM
Cron Daemon Cron <root> echo REBOOT 9:10:35 AM
Cron Daemon Cron <root> echo REBOOT 9:11:28 AM
Cron Daemon Cron <root> echo REBOOT 9:12:20 AM
Cron Daemon Cron <root> echo REBOOT 9:13:17 AM
Cron Daemon Cron <root> echo REBOOT 9:14:00 AM
Cron Daemon Cron <root> echo REBOOT 9:15:00 AM
Cron Daemon Cron <root> echo REBOOT 9:15:49 AM
Cron Daemon Cron <root> echo REBOOT 9:16:40 AM
Cron Daemon Cron <root> echo REBOOT 9:17:28 AM
Cron Daemon Cron <root> echo REBOOT 9:18:21 AM
Cron Daemon Cron <root> echo REBOOT 9:19:08 AM
Cron Daemon Cron <root> echo REBOOT 9:19:54 AM
Cron Daemon Cron <root> echo REBOOT 9:20:37 AM
Cron Daemon Cron <root> echo REBOOT 9:21:36 AM
Cron Daemon Cron <root> echo REBOOT 9:22:32 AM
Cron Daemon Cron <root> echo REBOOT 9:23:01 AM
Cron Daemon Cron <root> echo REBOOT 9:23:54 AM
Cron Daemon Cron <root> echo REBOOT 9:24:38 AM
Cron Daemon Cron <root> echo REBOOT 9:25:18 AM
Cron Daemon Cron <root> echo REBOOT 9:26:11 AM
Cron Daemon Cron <root> echo REBOOT 9:27:00 AM
Cron Daemon Cron <root> echo REBOOT 9:27:52 AM
Cron Daemon Cron <root> echo REBOOT 9:28:43 AM
Cron Daemon Cron <root> echo REBOOT 9:29:32 AM
Cron Daemon Cron <root> echo REBOOT 9:30:29 AM
Cron Daemon Cron <root> echo REBOOT 9:31:18 AM
Cron Daemon Cron <root> echo REBOOT 9:32:18 AM
Cron Daemon Cron <root> echo REBOOT 9:33:13 AM
Cron Daemon Cron <root> echo REBOOT 9:33:34 AM
% uptime
10:43 up 1:09, 6 users, load averages: 5.57 5.49 5.42
Update: It happened again to one of my other machines! Check this shit out! I have no idea why this machine rebooted. It was not a power failure, and system.log provides no clues. This time the cron job was "date; uptime". Several hours after this happened, it reported:
% date; uptime...which means it booted up at 3:14 AM. And this is the firehose of email that was generated:
Wed Mar 16 09:39:03 PDT 2022
9:39 up 6:25, 3 users, load averages: 2.41 2.35 2.33
Tags: computers, doomed, firstperson, mac, webcasting
Just to confirm, this is on OSX?
Yup.
Any chance the cron daemon is restarting for some reason? Depending on where Apple actually got their crontab from, it may not have any tracking of actual "reboots" other than an assumption that crond runs on startup and persists from then onwards.
Possibly unrelated cron-reboot anecdote: Linux crond does attempt to track reboots via a lockfile, but at least on Debian/Ubuntu erasure of the reboot-tracking lockfile between boots was never explicitly performed and only assumed, because it was supposed to be stored on a tmpfs in /var somewhere. So when that filesystem is persistent, Cron never thinks it's rebooted.
The logs are for entries that ran or were scanned?
FWIW, this works in Mojave:
@reboot /bin/date +"%c REBOOT" >> /tmp/cron.log 2>&1
* * * * * /bin/date +"%c other" >> /tmp/cron.log 2>&1
… Gives:
# last -1 reboot
reboot ~ Mon Mar 14 13:43
# cat /tmp/cron.log
Mon Mar 14 13:44:17 2022 REBOOT
Mon Mar 14 13:45:00 2022 other
Mon Mar 14 13:46:00 2022 other
I would not have gotten 65 distinct emails from one reboot if it wasn't executing the job 65 times.
Sure is annoying and proof enough. But we couldn't know that, could we?
Correction: This is the crontab as it ran (with backslashes):
@reboot /bin/date +"%c REBOOT" >> /tmp/cron.log 2>&1
* * * * * /bin/date +"%c other" >> /tmp/cron.log 2>&1
Also note that it stopped about 47 minutes after the reboot. Why that duration? Why didn't it continue forever? We may never know.
From what
uptimesaid, the reboot time was ≈9:34, a good time to run that cron job (ideally) once. The question is in what kind of deliriumcrondwas before that, and if that instance or the rebooted one generated the 9:33:34 entry. (I hear M1 Macs boot quickly.)Yeah, I typed reboot at 9:34, and prior to that uptime was 26 days.
It does not boot particularly fast, being a Macmini7,1 10.15.7, though with SSD.
So maybe none of those emails were from this reboot but were from the previous instance? But all the emails came in after the reboot. So now I'm suspecting DST fuckery, but all the emails seemed to be labelled PDT, and all of the machines involved in the mail path know what time it is.
"Every program attempts to expand until it can
readhave mail errors"You always find the most delightfully fucked-up corners of the behaviour space for our elucidation. Thanks, it's almost like I've found my soulmate. My wife thinks it's only me that has this experience.
C.
I no longer trust MacOS's cron; I believe they put the effort into launchd, which actually starts cron according to cron's man page. My bet would be they've goofed up launchd so that it keeps scanning for modified crontab files and running the reboot action.
I use launchd tasks to run things at login which works for my usage but have not personally had to run something on reboot only. Google claims you can have plist files that have the RunAtLoad Key to accomplish the @reboot equivalent though, maybe with a LaunchOnlyOnce Key too.
I also dislike dealing with the goofy plist files so I end up using Launchd Task Scheduler to get 'job' details right, but that's just laziness. Presumably moving a plist file into /Library/LaunchDaemons with the right keys would accomplish the desired behavior in the convoluted reinvention of cron way.
Launchd plist files and systemd service files are fine for what they do (giving you options about daemon restarts, log files, users, etc.) but having to write a 30 line script just to run some dumb thing once an hour is stupid.
That update is fucked up!
What's with that one guy at 03:11:49 reporting from the future??
And those load averages are bananas. Looks like someone decided to do a bunch of shit all at once. I wonder what it would show if you added a "top -l1" or similar to the cron. (Maybe that would be too much compute on an already loaded machine and it would explode that much sooner.)