I’ve a launchd job that’s alleged to run a php script at 6am each day. The script runs quite a few backup-related duties. After upgrading to Monterey, the duty now not begins at its scheduled time.
I take advantage of Lingon X to manage it. Once I run it manually from Lingon X as a “take a look at”, it begins, however generally doesn’t end. Once I run the command from the terminal, the job begins and all the time runs to completion.
Right here is the plist:
<?xml model="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" " <plist model="1.0"> <dict> <key>Disabled</key> <false/> <key>EnvironmentVariables</key> <dict> <key>PATH</key> <string>/choose/native/bin:/choose/native/sbin:/usr/native/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Functions/jas/Keybase.app/Contents/SharedSupport/bin:/usr/native/sbin</string> </dict> <key>Label</key> <string>RH-backup</string> <key>ProgramArguments</key> <array> <string>/choose/native/bin/php</string> <string>/Customers/jas/Web sites/RepHunter/cron/RH-backup.php</string> </array> <key>RunAtLoad</key> <false/> <key>StandardErrorPath</key> <string>/Volumes/Backup1/RH-backup/dbtemp/stderr.log</string> <key>StandardOutPath</key> <string>/Volumes/Backup1/RH-backup/dbtemp/stdout.log</string> <key>StartCalendarInterval</key> <array> <dict> <key>Hour</key> <integer>6</integer> <key>Minute</key> <integer>0</integer> </dict> </array> <key>StartOnMount</key> <false/> </dict> </plist>
There’s by no means any output in both stderr.log or stdout.log.
The one suspicious sample is that it seems that when began manually, the job usually quits after a sure interval. For the reason that executable is a php script, the very first thing I checked was whether or not the script was timing out.
As a take a look at, I added set_time_limit(900) to the php script. That ought to not matter, as per the php documentation the script timeout doesn’t embody the time when system calls are made. The aim of the script is to make quite a few techniques calls. So it shouldn’t be consuming a number of run time by itself.
Plus this script has be working for a number of years with none such points.
After additional testing I found some issues, however not the answer.
Having the StandardOutPath and StandardErrorPath prevents the launchd job from operating. We had been considering that it was as a result of these paths had been set to exterior drives was inflicting an issue. We simply eliminated them fully. The script then runs.
The script runs and calls all of the exterior instructions. There are a few calls to rsync to repeat some information round together with from distant servers. That works high quality.
Then the script calls duplicity to extract a file from the backup set. Duplicity instantly exits with out extracting the file. That makes the remainder of the features within the script pointless.
When the script is run from the command line, it all the time works as anticipated. It additionally labored as anticipated as a launchd job for over two years underneath Mojave and Catalina. Solely after the improve to Monterey did the script lose its skill to write down information.
As a take a look at, I gave Full Disk Entry to duplicity. That makes no distinction.
Workaround is to run the script manually from the command line. That all the time works.
Why does Monterey block launchd jobs from writing information?
As one other take a look at, I moved all the intermediate information into /tmp/ with the hope that if a permissions difficulty could be revealed. That didn’t assist.
I added capturing of error output for the duplicity command. The next is the error output when run as a launchd job (sorry concerning the formatting–the code markup will not be working for this textual content so I put it in as a quote):
Traceback (innermost final): File “/choose/native/bin/duplicity”, line 117, in
with_tempdir(predominant) File “/choose/native/bin/duplicity”, line 103, in with_tempdir
fn() File “/choose/native/Library/Frameworks/Python.framework/Variations/3.9/lib/python3.9/site-packages/duplicity/dup_main.py”,
line 1522, in predominant
motion = commandline.ProcessCommandLine(sys.argv[1:]) File “/choose/native/Library/Frameworks/Python.framework/Variations/3.9/lib/python3.9/site-packages/duplicity/commandline.py”,
line 1158, in ProcessCommandLine
config.gpg_profile = gpg.GPGProfile() File “/choose/native/Library/Frameworks/Python.framework/Variations/3.9/lib/python3.9/site-packages/duplicity/gpg.py”,
line 92, in init
self.gpg_version = self.get_gpg_version(config.gpg_binary) File “/choose/native/Library/Frameworks/Python.framework/Variations/3.9/lib/python3.9/site-packages/duplicity/gpg.py”,
line 108, in get_gpg_version
res = gnupg.run([u”–version”], create_fhs=[u”stdout”]) File “/choose/native/Library/Frameworks/Python.framework/Variations/3.9/lib/python3.9/site-packages/duplicity/gpginterface.py”,
line 376, in run
course of = self._attach_fork_exec(gnupg_commands, args, File “/choose/native/Library/Frameworks/Python.framework/Variations/3.9/lib/python3.9/site-packages/duplicity/gpginterface.py”,
line 429, in _attach_fork_exec
self._as_child(course of, gnupg_commands, args) File “/choose/native/Library/Frameworks/Python.framework/Variations/3.9/lib/python3.9/site-packages/duplicity/gpginterface.py”,
line 468, in _as_child
os.execvp(command, command) File “/choose/native/Library/Frameworks/Python.framework/Variations/3.9/lib/python3.9/os.py”,
line 574, in execvp
_execvpe(file, args) File “/choose/native/Library/Frameworks/Python.framework/Variations/3.9/lib/python3.9/os.py”,
line 616, in _execvpe
increase last_exc File “/choose/native/Library/Frameworks/Python.framework/Variations/3.9/lib/python3.9/os.py”,
line 607, in _execvpe
exec_func(fullname, *argrest) FileNotFoundError: [Errno 2] No such file or listing
GPGError: failed to find out gnupg model of None from b”
Looking on that error message “GPGError: failed to find out gnupg model …”, I discovered a web page at https://bugs.launchpad.internet/duplicity/+bug/1865427. That web page steered that for cron jobs including –gpg-binary with the trail to gpg.
I attempted that, however the launchd job nonetheless didn’t work.
Previous to the Monterey improve, gpg was on the default path utilized by the launchd job, for no matter purpose. Configuration modifications because of the OS improve precipitated it now not to be on that default path. So beforehand it was not vital to regulate the trail for the launchd script, however now it’s. Fixing that up solved this difficulty. So marking this query as answered.