Hilfe: script per launchctl automatisch starten - bekomme Fehler

jteschner

jteschner

Aktives Mitglied
Thread Starter
Dabei seit
30.05.2006
Beiträge
4.289
Reaktionspunkte
2.576
Ich versuche per launchctl ein script regelmäßig automatisch zu starten und habe mich deswegen ein wenig schlau gemacht und zum testen:
1. in /Users/jt/Downloads/ das script "Test1.sh" erstellt und ausführbar gemacht
Code: 
#!/bin/bash
echo "Dies ist ein Test"

2. in ~/Library/LaunchAgents das xml "com.jt.test.plist" erstellt
Code: 
<?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>Label</key>
    <string>com.jt.test</string>
    <key>Program</key>
    <string>/Users/jt/Downloads/Test1.sh</string>
    <key>StartInterval</key>
    <integer>60</integer>
    
    <key>UserName</key>
    <string>jt</string>
    
    <key>StandardErrorPath</key>
    <string>/Users/jt/Downloads/Test1.err</string>
    <key>StandardOutPath</key>
    <string>/Users/jt/Downloads/Test1.log</string>
</dict>
</plist>

3. das Ganze geladen
Code: 
launchctl load com.jt.test.plist

Ergebnis:
- das laden per launchctl klappte
- nach 60s wurden wie gewünscht die beiden log-files Test1.err und Test1.log angelegt
- Allerdings: Test1.log leer
- und Test1.err enthielt:
Code: 
/bin/bash: /Users/jt/Downloads/Test1.sh: Operation not permitted

Ich bin sicher, das es ein simples Problem ist. Ich sehe es aber nicht.
Kann jemand bitte helfen?
 
Darf das Script eventuell nichts ausgeben an Standard Out?
Oder du musst in der Shell umleiten.
 
Verschiebe / kopiere alles in einen "harmloseren" Ordner (Dokumente o.ä.)

"Downloads" steht unter allerlei Überwachung und reagiert manchmal seltsam.
Ggf. muss dein Skript auch "Festplattenvollzugriff" haben.
 
Also ich habe nun mal das #!/bin/bash aus dem script rausgenommen, so dass nur noch echo "Dies...." drin. steht.

Ergebnis:
Fehler in Test1.err ist weg aber Test1.log ist auch leer - also das echo "...." kommt dort nicht an.

Also wegen Permissions auf "Downloads": die output Dateien werden ja erzeugt, sollte also nicht das Problem sein
 
oneOeight schrieb:
Darf das Script eventuell nichts ausgeben an Standard Out?
Oder du musst in der Shell umleiten.
Zum Vergrößern anklicken....
Nun habe ich die Umleitung im script probiert:
Code: 
echo "Dies ist ein Test" >>/Users/jt/Downloads/Test1.out

Geht vom Terminal aus - aber nicht durch launchctl

Keinerlei Fehlermeldungen :-/
 
jteschner schrieb:
wegen Permissions auf "Downloads"
Zum Vergrößern anklicken....
Wie heißt's so schön:
  • Man hat schon Pferde kotzen sehen
POSIX ist nicht gemeint. Eher die diversen Xprotect - Remediator - Gatekeeper (oder wie das heißt) - what-have-you's. Weiß man nie.
 
Den Shebang kannst nicht weglassen, sonst musst das beim launchd Aufruf machen.

Versuch mal den Bash Prozess Festplattenvollzugriff zu geben.
 
oneOeight schrieb:
Dem bash Binary, also /bin/bash.
Mit Gehe zu Ordner /bin aufmachen und dann bash im den Dateidialog ziehen.
Zum Vergrößern anklicken....
Habe ich gemacht.
Ergebnis: Geht! Jede Minute wird das script gestartet und Test1.out ergänzt.
Code: 
#!/bin/bash
echo "Dies ist ein Test" >>/Users/jt/tmp/Test1.out

Allerdings behagt es mir nicht /bin/bash den Festplattenvollzugriff zu geben ... geht das nicht auch anders?
Denn vom Terminal aus als jt geht es doch auch und so wie ich die Doku verstanden habe, wird doch der launchctl als User ausgeführt - bei mir "jt".
 
jteschner schrieb:
Allerdings behagt es mir nicht /bin/bash den Festplattenvollzugriff zu geben ... geht das nicht auch anders?
Zum Vergrößern anklicken....
Gute Frage, wahrscheinlich müsstest du deinem Script dann entsprechende Credentials verpassen, damit die das zur Laufzeit genehmigt bekommen.

Sonst halt echo verzichten und die entsprechenden Ausgaben über die Log Facilities zu machen.

Weiß auch nicht, ob Apple inzwischen zu so was eine Technote bzgl Unix Scripts und Datenschutz Einstellungen veröffentlicht hat.
 
jteschner schrieb:
Allerdings behagt es mir nicht /bin/bash den Festplattenvollzugriff zu geben ... geht das nicht auch anders?
Zum Vergrößern anklicken....

das musst du auch nicht. Terminal.app reicht.

Zudem iust es empfehlenswert zsh statt bash zu nutzen. zsh ist bash-komptibel aber mächtiger. Und weitaus aktueller.

Wenn du öfters was mit launchd machen willst, besorge dir die App LaunchControl. Das ist eines der besten Tools, das ich kenne. Jeden Cent wert.
 
lisanet schrieb:
das musst du auch nicht. Terminal.app reicht.
Zum Vergrößern anklicken....
die hatte es bereits - und es ging nicht. Erst nachdem /bin/bash Vollzugriff hatte.

lisanet schrieb:
Zudem iust es empfehlenswert zsh statt bash zu nutzen. zsh ist bash-komptibel aber mächtiger. Und weitaus aktueller.
Zum Vergrößern anklicken....
Habe ich gerade probiert:
in Test1.err:
Code: 
/bin/zsh: can't open input file: /Users/jt/Downloads/Test1.sh
obwohl Rechte 755

zurück auf /bin/bash (und bash ohne FP-Vollzugriff):
Code: 
/bin/bash: /Users/jt/Downloads/Test1.sh: Operation not permitted
lisanet schrieb:
Wenn du öfters was mit launchd machen willst, besorge dir die App LaunchControl. Das ist eines der besten Tools, das ich kenne. Jeden Cent wert.
Zum Vergrößern anklicken....
eigentlich will ich nur mein backup.sh (enthält ein par rsnc Kommandos) täglich einmal automatisch gestartet haben und in einem log-file sehen, dass dass auch passiert ist.
 
lisanet schrieb:
das musst du auch nicht. Terminal.app reicht.
Zum Vergrößern anklicken....
Kontext beachten, das Shell Script wird über launchd gestartet und nich über das Terminal.

Damit der Festplattenvollzugriff vom Terminal greift müsste mal dann den Umweg über Applescript/osascript gehen oder ein .command benutzen.
 
Um solchen Hintergrund-Skripts "Festplattenvollzugriff" zu geben, habe ich selbst bereits
  • das Shell-Skript in ein Automator-Programm verpackt und diesem das entsprechende Recht gegeben
    .
Tante Google erzählt mir, dass
(nicht selbst getestet)
Bildschirmfoto 2024-01-13 um 14.52.47.png
 
Zuletzt bearbeitet:
Besten Dank soweit!
Ich muss mir das mal näher/tiefer anschauen -- ist zwar kein Hexenwerk aber doch schon etwas anspruchsvoller
Um mein backup-script zunächst einmal täglich automatisch ablaufen zu lassen, habe ich es temporär bei "bash-Vollzugriff" gelassen und ein .plist dafür erzeugt. Morgen sollte das dann starten ... so ich denn alles soweit richtig konfiguriert habe ;-)

Und dann baue ich das ggf. in ein Automator-Programm, ..... um. Aber alles der Reihe nach
 
jteschner schrieb:
die hatte es bereits - und es ging nicht. Erst nachdem /bin/bash Vollzugriff hatte.
Zum Vergrößern anklicken....

Kann nicht sein. Dann liegt es an was anderem. Ich muss es bei mir ja auch nicht machen und habe nur Terminal.app berechtigt und niemals bash

jteschner schrieb:
Habe ich gerade probiert:
in Test1.err:
Code: 
/bin/zsh: can't open input file: /Users/jt/Downloads/Test1.sh
obwohl Rechte 755
Zum Vergrößern anklicken....

Du musst natürlich Terminal.app auf zsh umgestellt haben und im script #!/bin/zsh stehen haben anstatt #!/bin/bash. Und du solltest auch sicherstellen, dass die .zshrc, .zprofile usw. bestehen, statt die bash-eigenen config-Dateien.

jteschner schrieb:
zurück auf /bin/bash (und bash ohne FP-Vollzugriff):
Code: 
/bin/bash: /Users/jt/Downloads/Test1.sh: Operation not permitted
[/QUOTE]

dann liegt es an was anderem. Ic
h vermute mal ...

[QUOTE="jteschner, post: 12166781, member: 55311"]

eigentlich will ich nur mein backup.sh (enthält ein par rsnc Kommandos) täglich einmal automatisch gestartet haben und in einem log-file sehen, dass dass auch passiert ist.
Zum Vergrößern anklicken....

... an dem binary von rsync. Das rufst du nämlich auch und das benötigt die entsprechenden Berechtigungen. Sprich: Terminal.app + rsync.

Da du bash berechtigst, erhalten alle child-Prozesse der bash auch die Berechtigung , so dass du rsync nicht separat berechtigen muss. rsync musst du deswegen berechtigen, da du da selbst installierst hast (hatten wir ja im anderen Thread) und nicht das macOS-interne rsync verwendest.

Also: Terminal.app braucht den Zugriff und die jeweiligen binaries, die du in LaunchAgents oder LaunchDaemons verwendest. Aber wie du schon sagst, nicht bash.

Und noch zwei Tipps: starte dein backup script direkt und nicht über ein anderes script. Weiterhin: die Endung ".sh" ist nicht notwendig und bringt keinerlei Vorteile, wichtig ist lediglich das gesetzte executable-bit
 
MrChad schrieb:
Um solchen Hintergrund-Skripts "Festplattenvollzugriff" zu geben, habe ich selbst bereits
  • das Shell-Skript in ein Automator-Programm verpackt und diesem das entsprechende Recht gegeben
    .
Tante Google erzählt mir, dass
(nicht selbst getestet)
Anhang anzeigen 419375
Zum Vergrößern anklicken....

es braucht weder osascript noch fdautil (das war vor langer Zeit mal notwendig).

Es reicht Terminal.app (braucht man ohnehin, wenn man damit arbeitet) und das jeweilige binary, das in einem shellscript aufgerufen wird und nicht zum Standardumfang von macOS gehört. Das Shellscript selbst braucht keine derartige Berechtigung.
 
lisanet schrieb:
Kann nicht sein. Dann liegt es an was anderem. Ich muss es bei mir ja auch nicht machen und habe nur Terminal.app berechtigt und niemals bash
Zum Vergrößern anklicken....
tja
lisanet schrieb:
Du musst natürlich Terminal.app auf zsh umgestellt haben und im script #!/bin/zsh stehen haben anstatt #!/bin/bash. Und du solltest auch sicherstellen, dass die .zshrc, .zprofile usw. bestehen, statt die bash-eigenen config-Dateien.
Zum Vergrößern anklicken....
ist

lisanet schrieb:
... an dem binary von rsync. Das rufst du nämlich auch und das benötigt die entsprechenden Berechtigungen. Sprich: Terminal.app + rsync.
Zum Vergrößern anklicken....
???? Schau doch mal in meinen ersten Post. Meine ganzen ersten Tests gehen um ein Script mit dem Inhalt --> echo "Dies ist ein Test"
In dem Post ist auch alles andere drin.
Natürlich habe ich in der Folge alle vorgeschlagenen Änderungen auch durchgeführt - ich bin ja nicht ganz dumm ;-)
 
@lisanet
Ich habe nun nochmals:
- im script #!/bin/zsh eingetragen
- sichergestellt, dass das "Terminal" Vollzugriff hat und auf /bin/zsh als Standard hat (erweiterte Optionen in meinem User-Profil)
- bash Vollzugriff entzogen

Fehlermeldung in Test1.err: /bin/zsh: can't open input file: /Users/jt/Downloads/Test1.sh

Hier mein script "Test1.sh"
Code: 
#!/bin/zsh
echo "Dies ist ein Test"

Hier mein plist file com.jt.test.plist:
Code: 
<?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>Label</key>
    <string>com.jt.test</string>
    <key>Program</key>
    <string>/Users/jt/Downloads/Test1.sh</string>
   
    <key>StartInterval</key>
    <integer>60</integer>
   
    <key>StandardErrorPath</key>
    <string>/Users/jt/Downloads/Test1.err</string>
    <key>StandardOutPath</key>
    <string>/Users/jt/Downloads/Test1.log</string>
</dict>
</plist>

Ändere ich nur im script Test1.sh zsh in bash und gebe der bash Vollzugriff funzt es.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.

Ähnliche Themen

Atalantia
launchd kann kein bash Skript ausführen.
Antworten
18
Aufrufe
507
Atalantia
Atalantia
Zurück
Oben Unten