3

I'm trying to run a script (zfssnap.sh) to automate snapshots, but one of the arguments needs to change based on which time entry triggers the script to start. With cron, I would just add a new line with the changed argument and set the time fields accordingly.

In reading the launchd and launchd.conf man pages, I'm not seeing any way to associate an argument with a specific StartCalendarInterval key entry. This seems like a significant limitation, so perhaps I'm missing something?

Is there a way change an argument based on the time the script is being run? Or, do I have to make a new plist for each of the situations I'm trying to satisfy?

grg
  • 201,078
  • 2
    Do it in a bash script that actually changes program arguments. See this example: https://apple.stackexchange.com/questions/334534/is-it-possible-to-allow-usage-for-an-app-or-program-for-a-specific-time-on-mac/334569#334569 – Allan Sep 06 '18 at 19:31
  • 1
    That might work. I can spread the times a bit to make for a more decisive test. – tim.rohrer Sep 06 '18 at 20:35

1 Answers1

1

The "standard" thing to do is make a new .plist for each different time/argument combo. This is essentially the equivalent of making multiple entries in the crontab, except that each "entry" is an entire file, not just a line.

There's a good example of this in macOS's launch daemon entries for the periodic maintenance program. /System/Library/LaunchDaemons/com.apple.periodic-daily.plist runs /usr/libexec/periodic-wrapper with the argument "daily" and a 24-hour interval, ...periodic-weekly.plist runs it with the argument "weekly" and a 7-day interval, and ...periodic-monthly.plist runs it with the argument "monthly" and a 30.44-day interval.

  • I decided to go this way, but what a PITA. I wish Apple would make this more flexible since they've deprecated cron. In any case, I'm still having trouble getting one of them to work. The argument is <string>pool/dataset</string> and I'm thinking launchd is treating as a path instead of a simple argument being passed to the script. I may still have to run a separate script for that one. – tim.rohrer Sep 08 '18 at 02:12
  • @tim.rohrer It should be treated as a plain string, with no interpretation at all applied (it doesn't even expand ~ or wildcards unless you set the EnableGlobbing key). Can you tell what the script is receiving as its argument? – Gordon Davisson Sep 08 '18 at 02:18
  • zxfer from https://github.com/allanjude/zxfer. The launchd status code is 3, which I've not yet been able to find defined. I can take the same command line and arguments from the plist and it appears to run successfully. Here is a pastebin of the plist: https://pastebin.com/VAeGeN4E – tim.rohrer Sep 08 '18 at 03:09
  • I'm not familiar with zxfer, but I don't see anything obviously wrong. One thing to check: do all of the .plists have different Label values? – Gordon Davisson Sep 08 '18 at 11:29
  • Yes, as I've made them match the filenames used. Any idea on what code 3 means? – tim.rohrer Sep 08 '18 at 18:03
  • 1
    I'd expect that to be a code from zxfer, but its man page says "exits 0 on success, 1 on an error and 2 if a command line option is incorrect"... so I don't know. Try adding StandardOutPath and StandardErrorPath keys (pointing to reasonable log locations) so you can see if it's printing any helpful errors. Also, check /var/log/system.log for messages from launchd (although I'm not sure it still sends anything useful there). – Gordon Davisson Sep 08 '18 at 18:16
  • I did not know the exit status code could/would be from the script/command being run. I’ll dig into the script; will try tomorrow. Thanks. – tim.rohrer Sep 09 '18 at 04:16