2

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
  • 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 at 12:41
  • 1
    On the mac - please edit your build and version. sw_vers will show you that data. – bmike Oct 14 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 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 at 21:45
2

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.

  • 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 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.

  • At least it didn't work without restarting, but I'll give it a go the next time I restart. – Thomas Jensen Oct 18 at 13:05
  • I've now tested this, and it unfortunately doesn't work. The problem is unchanged. – Thomas Jensen Oct 26 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 at 13:47
0

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .