Solange sie funktionieren ist alles gut, aber wehe sie gehen mal nicht…
Ich habe mehrere Systeme-Services aka LaunchDaemons laufen.
Das Problem ergibt sich, da die Source unter meinem Benutzer liegen, die Services aber auch laufen sollen, wenn ich nicht angemeldet bin. Bis ich macOS Big Sur 11.2.3 installiert hatte, lief alles gut. Plötzlich mag er es nicht mehr. Da habe ich dann den Besitzer auf root geändert (chown root), den 'anderen' Benutzern die Ausführung verboten (chmod o-r) die Ausgabe in Logfiles eingebaut, sicherheitshalber mittels xargs die erweiterten Dateiattribute - die erkennt man an dem @-Zeichen beim ls -l - einzeln gelöscht (xargs Datei; dann xargs -d 'einAttribut' Datei). Mittels „sudo launchctl load -w Datei“, „sudo launchctl start -w Datei“ und einem Neustart alles wieder hin bekommen.
Trotzdem es automatisch mit sudo gestartet wird, hat es nicht geklappt, dass ein script ordentlich läuft. Gut, ich hatte einen Programmierfehler in der Zeile, hätte aber vermutet, dass wenn man i einer Kommandozeile ein Date-Remote macht und sie dann wieder anlegt, dass das auch geht, wenn die Datei am Anfang nicht da ist…falsch gedacht, er bricht dann einfach ab.
Und wieder gab es Problem. Alles wieder zurück nach /Library/LaunchDaemonse und folgende Zeilen am Anfang eingebaut
<key>KeepAlive</key>
<false/>
<key>SessionCreate</key>
<true/>
<key>UserName</key>
<string>(username)</string>
<key>StandardErrorPath</key>
<string>/var/log/launchDaemon.log</string>
<key>StandardOutPath</key>
<string>/var/log/launchDaemon.log</string>
Und wieder was gelernt:
Service could not initialize: 20D91: xpcproxy + 23862 [839][60F99144-8057-38E2-8AC6-AD60B93E6E6B]: 0xd Service exited with abnormal code: 78
Das bedeutete wohl, dass der Service nicht das Logfile speichern konnte, dass ich angegeben habe. Erst mit chmod 777, einem unload und einem load ohne sudo ging es dann.
Der Versuch, es von /Library/LaunchDaemons in meine eigenen LaunchAgent zu kopieren hat (wieder) nicht geklappt. Möglicherweise war es das gleiche Problem.
Zusätzlich kam noch die Meldung: „UserName is not supported for non-System services.“ Ich musste es also wieder entfernen, obwohl es gestern noch mit der Einstellung ging *seufz*
Im Juli habe ich wieder einen Systemupdate gemacht. Und die iTunes Steuerung mittels node ging wieder nicht. Die Lösung, wenn ich auch nicht genau weiss wieso war wie folgt:
sudo launchctl stop -w /Library/LaunchDaemons/nu.mine.nodejs_itunes.plist sudo launchctl unload -w /Library/LaunchDaemons/nu.mine.nodejs_itunes.plist launchctl unload -w /Library/LaunchDaemons/nu.mine.nodejs_itunes.plist sudo rm /var/log/launchDaemon_iTunes* die beiden Logfiles unter "/var/log/launchDaemon_iTunes*" gelöscht sudo /usr/local/bin/node /Users/xxx/Programmieren/itunes_server/index.js Einmal ausprobieren sudo launchctl load -w /Library/LaunchDaemons/nu.mine.nodejs_itunes.plist [dann 'snips Musik an' und in den Einstellungen node erlauben, darauf zuzugreifen] sudo nano /var/log/launchDaemon_say_lina.log sudo nano /var/log/launchDaemon_say.log sudo chmod 777 /var/log/launchDaemon_say.log sudo chmod 777 /var/log/launchDaemon_say_lina.log sudo chmod 777 /var/log/launchDaemon_iTunes*
Kontrollfelder: Apps für die Bedienungshilfe die Steuerung dieses Computers erlauben {Node auf true setzen}
Neue Version, neuer Versuch - November 2023 Sonoma 14.1.1
irgendwann dann einen Neustart, sonst geht das mit node nicht es muss die Finder-Meldung kommen, dass node Zugriff braucht. node Berechtigungen unter: Einstellungen→Datenschutz & Sicherheit→Bedienungshilfen→node Zum Schluss müssen die iTunes_logs root/wheel, -rw-r–r– haben
Stand November 2023