Mit manchen Problemen kann man sich die ganze Nacht um die Ohren schlagen, obwohl die Lösung doch eigentlich so einfach herauszufinden wäre. Vielleicht lag das eigentliche Problem auch an fortgeschrittener Stunde.

Jedenfalls plagte ich mich bei einem neu aufgesetzten Server mit einer nicht funktionierenden Update-Funktion von TinyTiny RSS herum. Ein Must-Have!

Per launchd wird im gewünschten Intervall ein php-Skript ausgeführt, welches nach neuen Artikeln sucht und diese in der Datenbank speichert. Auf dem neuen Server regte sich allerdings nichts und in der Log-Konsole erschien folgede un-aussagekräftige Fehlermeldung nach dem Starten des launchdDienstes:

Jun  6 23:47:03 apfelz-server com.apple.xpc.launchd[1]
 (net.apfelz.update_feeds[27462]): Service could not initialize:
17G12034: xpcproxy + 11458 [1524][32B22DEC-BDC5-30DF-A817-217B98F95BE1]: 0xd

Berechtigungsproblem

launchd und Berechtigungen ist so eine Sache, deshalb ging ich schon anfangs davon aus, dass es sich um eine Berechtigungs-Problematik handelt. Suchte nur ewig lang an der falschen Stelle.

Zuerst: Diese .plist-Datei liegt unter /Library/LaunchDaemons und der ausführende User sollte _www sein, das auszuführende .php-Skript gehört ebenso dem User _www

Finde den Fehler:

/Library/LaunchDaemons/net.apfelz.update_feeds.plist
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
   <key>UserName</key>
   <string>_www</string>
   <key>GroupName</key>
   <string>staff</string>
   <key>Label</key>
   <string>net.apfelz.update_feeds</string>
   <key>ProgramArguments</key>
   <array>
      <string>/usr/bin/php</string>
      <string>/Library/WebServer/Documents/reader.apfel-z.net/update.php</string>
      <string>--feeds</string>
      <string>--quiet</string>
   </array>
   <key>RunAtLoad</key>
   <true/>
   <key>StandardErrorPath</key>
   <string>/var/log/reader_update_feed_err.log</string>
   <key>StandardOutPath</key>
   <string>/var/log/reader_update_feed.log</string>
   <key>StartInterval</key>
   <integer>900</integer>
   <key>WorkingDirectory</key>
   <string>/Library/WebServer/Documents/reader.apfel-z.net/</string>
</dict>
</plist>

Dies ist nur ein kleiner Tipp, seinen Blick nicht nur auf die offensichtlichen Dinge zu beschränken und auf die Kleinigkeiten zu achten, die man ansonsten nur als nebensächlich betrachtet:
Im Endeffekt waren das Problem nicht ein falscher User oder eine falsche Gruppe oder die .plist-Datei im falschen Verzeichnis oder falsche Berechtigungen der .php-Datei oder sonstigen involvierten Dateien, sondern StandardErrorPath und StandardOutPath, da der User _www keine Schreibberechtigung auf /var/log/ hat.
Die beiden Pfade auf ein Verzeichnis zu ändern, auf welches _www Schreibberechtigung hat, lösten das Problem.

Kleine Ursache, große Wirkung!

Nicht gefundene Pfade

Ein anderes Mal bei einem python3-Skript, welches ich per launchd laufen lassen wollte, hatte ich eine ähnliche Fehlermeldung:

Service could not initialize: 17G12034: xpcproxy + 11458 1524 32B22DEC-BDC5-30DF-A817-217B98F95BE1: 0x2

Nachdem ich wieder ewig an den Berechtigungen rumgeschraubt und getestet hatte, kam ich irgendwann darauf, dass launchd python3 nicht finden kann.

Statt in der launchd-plist-Datei

<key>ProgramArguments</key>
  <array>
    <string>python3</string>
    <string>/server/scripts/meinTask.py</string>
  </array>

musst ich

<key>ProgramArguments</key>
  <array>
    <string>/usr/local/bin/python3</string>
    <string>/server/scripts/meinTask.py</string>
  </array>

verwenden.

Auch wenn man auf der Kommandozeile das Skript ganz simpel mit einem
python3 /server/scripts/meinTask.py
ausführen konnte.