10

I have cronjobs doing various cleanup tasks:

$ crontab -l
0 * * * * find ${HOME}/Downloads -depth 1 -d -mtime +12h -exec /usr/local/bin/trash {} \;
* * * * * /usr/bin/defaults delete com.apple.Spotlight userHasMovedWindow > /dev/null
* * * * * /usr/bin/defaults delete com.apple.Spotlight windowHeight > /dev/null

However, it seems the jobs, for some reason, never exits. Instead they linger on and show as (cron) companioned by either (find) or (defaults) in the output of ps and in the activity monitor.

It happens for all jobs.

After hours or days, the computer freezes as the OS won't allow any more processes to spawn.

$ sw_vers 
ProductName:    Mac OS X
ProductVersion: 10.15
BuildVersion:   19A583
Thomas Jensen
  • 280
  • Can you check what the commands output in a terminal as the user running this crontab? This may provide some insight on why they aren't exiting properly (as they should). – rbanffy Oct 14 '19 at 12:41
  • 1
    On the mac - please edit your build and version. sw_vers will show you that data. – bmike Oct 14 '19 at 14:59
  • 1
    Running as root or my own user gives the same output:

    $ sudo /usr/bin/defaults delete com.apple.Spotlight windowHeight > /dev/null 2019-10-14 23:30:42.514 defaults[10252:339670] Domain (com.apple.Spotlight) not found. Defaults have not been changed.

     – Thomas Jensen Oct 14 '19 at 21:32
  • 2
    Thanks! Cron is stuck / hamstrung / easily foiled on a lot of security hoops on Catalina. I might put up an answer to just use launchd and here’s how to get started away from cron – bmike Oct 14 '19 at 21:45

3 Answers3

5

Redirect stderr to /dev/null as well as stdout:

* * * * * /usr/bin/defaults delete com.apple.Spotlight userHasMovedWindow &> /dev/null
* * * * * /usr/bin/defaults delete com.apple.Spotlight windowHeight &> /dev/null

From trial and error it seems to be the stderr output of those commands that prevents the cronjob from exiting. I have no clue why that is, but it may be related to permissions to mail the output.

Thomas Jensen
  • 280
  • This is consistent with my experience that cron processes (but not their children) linger around - as if cron hangs trying to write to the mail spool? But lsof shows no open files from it. Do you have any idea what's going on? – Matt Jones Nov 25 '19 at 03:16
  • I have a similar suspicion, but I have no more ideas on how to debug from here. – Thomas Jensen Dec 03 '19 at 15:38
  • 2
    I confirmed the issue is that cron on macOS Catalina gets stuck trying to email the stdout/stderr of the job. Giving cron "full disk access" does not fix the issue. See also https://www.reddit.com/r/MacOS/comments/dfxlvg/con_jobs_not_firing_after_upgrading_to_catalina/ and https://discussions.apple.com/thread/250857074. lsof shows the cron process has fd 5 open on a pipe that is not attached to any other process. It's unclear if that is important since lldb can't attach to the process due to S.I.P. – Kurtis Rader Dec 14 '19 at 02:59
  • I was suspecting MacOS deep failure or harddisk failures. It freezed whole system, crash Dock or Spotlight, my terminal refused to open new session (too many processes, unable to fork....) .... that was the good clue to investigate .. and I've noticed more than 3000 (cron) processes.

    Thanks a lot. Works like a charm

     – Damien C Jan 02 '20 at 15:02
1

The traditional UNIX way of preventing a program from having multiple copies running is with a .pid (or lock) file. The following example appears on multiple places:

#!/bin/sh

NAME=$(basename "$0")

if [ -f /var/run/"$NAME.pid" ] &&
  ps -p $(cat /var/run/"$NAME.pid") >/dev/null 2>&1
then
   echo "Script is currently in progress... aborting..."
   exit 3
fi

# Remove the .pid file on exit (by setting a trap)
trap 'rm -f /var/run/"$NAME.pid"' EXIT

# Echoes the current PID to the .pid file
echo $$ > /var/run/"$NAME.pid"

The downside is that you'd need to move your commands into script files.

Disclaimer: you still need to figure out why the programs don't exit as they should, but this allows you to, at least, not overtax your system. You can also opt yo kill the offending PID instead of exiting the newly started script.

rbanffy
  • 167
  • 1
    Well, yes, I could have every job kill the previous one, or have yet another cronjob cleaning up cronjobs, but those are just workarounds. I'm interested in finding the culprit. – Thomas Jensen Oct 14 '19 at 21:27
0

Have you granted full disk access to your cron executable?

System Preferences needs to allow that task to write and read for most use cases. I would restart and then make this change and watch.

bmike
  • 235,889
  • At least it didn't work without restarting, but I'll give it a go the next time I restart. – Thomas Jensen Oct 18 '19 at 13:05
  • I've now tested this, and it unfortunately doesn't work. The problem is unchanged. – Thomas Jensen Oct 26 '19 at 11:44
  • I now see I was thinking you had multiple cron as proposed to cron launching too many sub tasks. Sorry for the side trip looking at cron itself @ThomasJensen – bmike Oct 26 '19 at 13:47