launchd kann kein bash Skript ausführen.

Atalantia

Atalantia

Aktives Mitglied
Thread Starter
Dabei seit
26.11.2009
Beiträge
1.894
Reaktionspunkte
432
Hallo,
ich schrieb ein Script das durch den Inhalt eines Verzeichnisses geht und jede Datei auflistet.
Bash: 
#!/bin/bash

for i in $HOME/Downloads/Browsers/* ; do
   echo "$i" >> $HOME/Desktop/test.txt
done
Wenn ich das mit Terminal aufrufe funktioniert es und das Ergebnis sieht folgendermassen aus:
Code: 
/Users/test/Downloads/Browsers/2023-06-13
/Users/test/Downloads/Browsers/2023-12-23
/Users/test/Downloads/Browsers/2023-12-29
/Users/test/Downloads/Browsers/2024-01-02
/Users/test/Downloads/Browsers/2024-01-04
/Users/test/Downloads/Browsers/2024-01-06
/Users/test/Downloads/Browsers/2024-01-07
/Users/test/Downloads/Browsers/2024-01-08
/Users/test/Downloads/Browsers/2024-01-10
/Users/test/Downloads/Browsers/2024-01-11
/Users/test/Downloads/Browsers/2024-01-16
/Users/test/Downloads/Browsers/2024-02-25
/Users/test/Downloads/Browsers/CE727493107CH.pdf
11 Verzeichnisse, 1 Datei.
Wenn ich das Script aber über einen launchd agent starte sieht das Ergebnis so aus:
Code: 
/Users/test/Downloads/Browsers/*
Der launchAgent sieht so aus:
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>Disabled</key>
    <false/>
    <key>Label</key>
    <string>BrowserDLbyDate</string>
    <key>Program</key>
    <string>/Users/test/Library/Scripts/BrowserDLbyDate1</string>
    <key>ProgramArguments</key>
    <array>
        <string>bash</string>
    </array>
    <key>StartCalendarInterval</key>
    <dict>
        <key>Hour</key>
        <integer>0</integer>
        <key>Minute</key>
        <integer>1</integer>
    </dict>
</dict>
</plist>
Weiss jemand wo der Fehler ist?
PS: Das Problem besteht für alle Skripte die irgendwie durch ein Verzeichnis iterieren müssen.
Das Problem besteht systemweit. Auch mit einem anderen User funktioniert es nicht.
 
Zuletzt bearbeitet:
Die Shell im Terminal ist zsh, im Skript erzwingst du aber bash.

bash denkt sich da wohl was anderes als zsh aus.
 
Setze mal dein Directory direkt, nicht über $HOME.
 
  • Gefällt mir
Reaktionen: mausfang, Atalantia und wegus
Ich habe das im Skript auf zsh geändert und im launchAgent. Kein Erfolg. Immer noch Fehler. Es wird im Script ja gesagt, das bash die Shell ist. Sollte also auch von bash ausgeführt werden oder verstehe ich da etwas falsch?
 
Für mich sieht der launchAgent irgendwie "krumm" aus ...
Debuggen werde ich aber nicht.
Ich habe mir nach ein paar Problemen, die ich selbst mit diesen Sachen hatte, die LaunchControl.app gekauft. Damit kann ich nun sauber und einfach lauchagents erstellen und debuggen.
Du kannst auch mal bei ChatGPT deinen lauchagent erstellen lassen - geht recht gut.
 
Ja @MrChad , in diese Richtung ging das ... der verlinkte Thread sollte helfen. Am Ende hatte ich sehr viel Internet Recherche betrieben :)
Es hatte alles etwas mit Berechtigungen, "Festplattenzugriff" für die Terminal.app, absoluten Pfaden, ... zu tun. Aber weniger mit zsh oder bash - bzw nur am Rande.
Ich starte auch bash-scripte über den launchd.
Nichtsdestotrotz denke ich, dass etwas (auch) mit seinem launchagent zu tun hat. Ohne nun genauer zu analysieren: da stimmt was nicht - so meine ich.
Auch fehlen einige Infos wie: ist es ein persönlicher agent, stimmt der Pfad, wird richtig gestoppt/gestartet, ...
Das alles ließe sich mit LaunchControl super managen. Damit habe ich meine nun 5 launchAgents problemlos aufsetzen können. Die 20€ haben mir viel Zeit gespart.
 
  • Gefällt mir
Reaktionen: Atalantia
Nein! Das Skript lief einwandfrei mit diesem launchAgent. Das Script liegt im Ordner ~/Library/Scripts. Aber wie gesagt... das Script lief einwandfrei bis ich einen P/R Reset machte.
@jteschner 5 launchAgents? Ich habe ca. 25. Alle die durch ein Verzeichnis iterieren müssen laufen nicht mehr. Ich habe versucht das Script aus /usr/local/bin zu starten, den Owner und Privileges auf System; Wheel zu legen und vieles mehr. Nix kann launchd dazu bewegen das Script korrekt auszuführen. Das Script wird gestartet aber es kann nicht durch das Verzeichnis iterieren.
 
Atalantia schrieb:
Nein! Das Skript lief einwandfrei mit diesem launchAgent. Das Script liegt im Ordner ~/Library/Scripts. Aber wie gesagt... das Script lief einwandfrei bis ich einen P/R Reset machte.
@jteschner 5 launchAgents? Ich habe ca. 25. Alle die durch ein Verzeichnis iterieren müssen laufen nicht mehr. Ich habe versucht das Script aus /usr/local/bin zu starten, den Owner und Privileges auf System; Wheel zu legen und vieles mehr. Nix kann launchd dazu bewegen das Script korrekt auszuführen. Das Script wird gestartet aber es kann nicht durch das Verzeichnis iterieren.
Zum Vergrößern anklicken....
Ich kann dir nur sagen:
Für meine Scripte habe ich mir ein Verzeichnis ~/bin/ angelegt und diesem Standard Posix Rechte gegeben. Mit /usr/local/bin war ich auch nicht erfolgreich. Also nutze ich praktisch ein Verzeichnis, das nicht durch spezielle "Apple-Rechte" "verseucht" ist.
Logs landen in ~/Library/Logs/
LaunchControl zeigt mir immer konkrete Fehler und eine Konsole - was bislang auch immer geholfen hat. Außerdem kann ich praktisch bei den .plist Dateien keine Fehler mehr machen, da LaunchControl diese auf Basis von Drag'nDrop erstellt, an der richtigen Stelle speichert, starten/stoppen übernimmt, ...
 
  • Gefällt mir
Reaktionen: Atalantia und dg2rbf
Ach, und das fettgedruckte stört mich an deinem .plist auf den ersten Blick:

<key>Disabled</key>
<false/>
<key>Label</key>
<string>BrowserDLbyDate</string>
<key>Program</key>
<string>/Users/test/Library/Scripts/BrowserDLbyDate1</string>
<key>ProgramArguments</key>
<array>
<string>bash</string>
</array>

Was soll das Disabled "false/"?
Und unten übergibst du als Argument "bash " - im script wird das aber gar nicht verarbeitet
Also sagte ich: "Das .plist sieht für mich "krumm" aus. Ich bin aber kein Experte ...

Bei mir sieht ein typisches .plist so aus:

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>de.jt.backup</string>
    <key>Program</key>
    <string>/Users/jt/bin/backup.sh</string>
    <key>RunAtLoad</key>
    <true/>
    <key>StandardErrorPath</key>
    <string>/Users/jt/Library/Logs/de.jt.backup.log</string>
    <key>StandardOutPath</key>
    <string>/Users/jt/Library/Logs/de.jt.backup.log</string>
    <key>StartInterval</key>
    <integer>7200</integer>
</dict>
</plist>


oder mit "ProgramArguments" so:

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>de.jt.sync.drive</string>
    <key>ProgramArguments</key>
    <array>
        <string>/opt/homebrew/bin/rsync</string>
        <string>-av</string>
        <string>--iconv=utf-8-mac</string>
        <string>--exclude=.DS_Store</string>
        <string>--delete</string>
        <string>/Users/jt/Documents/Drive/</string>
        <string>jt@omv.local::dokumente/Drive</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
    <key>StandardErrorPath</key>
    <string>/Users/jt/Library/Logs/de.jt.sync.drive.log</string>
    <key>StandardOutPath</key>
    <string>/Users/jt/Library/Logs/de.jt.sync.drive.log</string>
    <key>WatchPaths</key>
    <array>
        <string>/Users/jt/Documents/Drive</string>
    </array>
</dict>
</plist>
 
Was sind Standard Posix Rechte?

Mit dem plist file ist alles in Ordnung.
<key>Disabled</key>
<false/>
ist ergreifend simple launchd fragt ob das plist deaktiviert ist. Antwort: Nein (false)
Das Programmargument ist eben genau das... es soll mit bash ausgeführt werden.
plist kann abgehackt werden es ist in Ordnung. Ausserdem wie weiter oben schon erwähnt, ist das file mit LaunchControl angelegt. Bitte meine Texte genau lesen.
Es hat etwas mit dem Zusammenspiel Script und launchd zu tun.
 
Eine Anzeige wie /Users/test/Downloads/Browsers/* also wo der Joker * nicht aufgelöst ist, bekommst du immer dann, egal welche Shell, wenn es das Verzeichnis nicht gibt oder derjenige Benutzer, der den Befehl aufruft, kein Recht hat, das Verzeichnis selbst zu lesen. Wenn du dein Skript über den launchd-Agenten startest, dann wird es von einem anderen Benutzer aufgerufen als wenn du es per Hand direkt startest, und jener andere Benutzer hat vermutlich nicht die passenden Rechte.

Da das Verzeichnis existiert, nehme ich an, dass es an den Rechten liegt. Wenn du
Bash: 
chmod 777 /Users/test /Users/test/Downloads /Users/test/Downloads/Browsers
eingibst, wird es vermutlich auch mit den launchd-Agenten funktionieren. (Merk dir vorher die Rechte der drei Verzeichnisse, um sie wieder herstellen zu können.)

Die saubere Lösung wäre, dass launchd das Skript als passender User ausführt. (Geht das überhaupt?)
 
  • Gefällt mir
Reaktionen: Atalantia
Atalantia schrieb:
Was sind Standard Posix Rechte?
Zum Vergrößern anklicken....
Unix/Linux Rechte ohne ACL/Apple-Specials
Atalantia schrieb:
Mit dem plist file ist alles in Ordnung.
<key>Disabled</key>
<false/>
ist ergreifend simple launchd fragt ob das plist deaktiviert ist. Antwort: Nein (false)
Zum Vergrößern anklicken....
Kann also raus wenn das ausgeführt werden soll
Atalantia schrieb:
Das Programmargument ist eben genau das... es soll mit bash ausgeführt werden.
Zum Vergrößern anklicken....
So geht das meines Wissens nach nicht.

Sondern beispielhaft so:
<key>ProgramArguments</key>
<array>
<string>/bin/sh</string>
<string>-c</string>
<string>rm /Users/jt/Library/Logs/de.jt.*.log</string>
</array>
Zum Vergrößern anklicken....

Aber nun halte ich mich raus.
 
  • Gefällt mir
Reaktionen: Atalantia
Sorry Doppelpost.
 
Zuletzt bearbeitet:
Johanna K schrieb:
Eine Anzeige wie /Users/test/Downloads/Browsers/* also wo der Joker * nicht aufgelöst ist, bekommst du immer dann, egal welche Shell, wenn es das Verzeichnis nicht gibt oder derjenige Benutzer, der den Befehl aufruft, kein Recht hat, das Verzeichnis selbst zu lesen. Wenn du dein Skript über den launchd-Agenten startest, dann wird es von einem anderen Benutzer aufgerufen als wenn du es per Hand direkt startest, und jener andere Benutzer hat vermutlich nicht die passenden Rechte.

Da das Verzeichnis existiert, nehme ich an, dass es an den Rechten liegt. Wenn du
Bash: 
chmod 777 /Users/test /Users/test/Downloads /Users/test/Downloads/Browsers
eingibst, wird es vermutlich auch mit den launchd-Agenten funktionieren. (Merk dir vorher die Rechte der drei Verzeichnisse, um sie wieder herstellen zu können.)

Die saubere Lösung wäre, dass launchd das Skript als passender User ausführt. (Geht das überhaupt?)
Zum Vergrößern anklicken....
Danke, das sind wirklich Informationen die weiterhelfen. Leider hat die Anpassung der Rechte nicht geholfen. Auch nicht nach einem Neustart. Aber generell sehe ich das auch so, dass es ein Problem der Rechte ist. Alle meine Skripte laufen mit launchd, ausser die welche durch ein Verzeichnis iterieren.
 
jteschner schrieb:
Ich kann dir nur sagen:
Für meine Scripte habe ich mir ein Verzeichnis ~/bin/ angelegt und diesem Standard Posix Rechte gegeben. Mit /usr/local/bin war ich auch nicht erfolgreich...
Zum Vergrößern anklicken....
Leider war auch das nicht von Erfolg gekrönt.
 
Danke an alle. Das Problem scheint nicht lösbar zu sein.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben Unten