Script mit rsync: manueller Start über Terminal läuft problemlos - über LaunchAgent Fehler

[jteschner]

Status: Änderungen teilweise zurückgedreht - läuft immer noch

Zurückgenommene Änderungen:
- auf dem NAS die "Authorisierung notwendig" für die rsync-server Module rausgenommen
- auf dem MBP das Backup-Script von "--password-......passwordfile.txt" bereinigt
- auf dem NAS die Parameter in der avahi-conf wieder auskommentiert

Weitere Tests:
1. Update homebrew
- brew update/upgrade gemacht
- brew rsync wurde u.a. auf v3.4.1 durchgeführt
- testweise einen (von 5) rsync Befehlen im Backup-script von /usr/local/bin/rsync auf /usr/homebrew/bin/rsync geändert
--> dieser eine brachte den bekannten Fehler, die anderen 4 liefen durch
2. Austausch rsync-binary in /usr/local/bin durch rsync-binary in homebrew
- /usr/local/bin/rsync umbenannt
- rsync aus homebrew nach /usr/local/bin kopiert
--> Backup-Script brachte den bekannten Fehler
- genaueres Hinschauen zeigte, dass der rsync von homebrew ca. 500kb groß ist, wärend der selbstkompilierte ca. 5MB hat - also offensichtlich anders kompiliert ist
--> Resultat: das funktioniert so nicht

Dort habe ich nun zunächst aufgehört.

Aktuelle Entscheidung:
- ich bleibe zunächst bei dem von mir selbst kompilierten rsync in /usr/local/bin (besten Dank an @lisanet für das script und die detaillierte Anleitung!)
- dies erscheint mir zunächst als nachhaltigste Lösung - bei konkretem Bedarf kann ich ja einen neuen rsync kompilieren

Offene Fragen:
- Warum funktioniert das mit Homebrew rsync nicht "einfach" so im Zusammenhang mit LaunchAgent?
--> meine Vermutung: die rsync binary von homebrew liegt, wenn sie aktualisiert wird, in einem neuen Verzeichnis (in diesem Fall /..../3.4.1/ ) und muss daher unter macOS zur Ausführung im LaunchAgent neu "registriert" werden
- Warum funktioniert der update bei anderen zB @lisanet problemlos (manuell startend wie automatisch über LaunchAgent)?
--> meine Vermutung: weil sie rsync selbst kompiliert und die binary immer unter /usr/local/bin liegt - sich der Pfad also nie ändert.

Feedback, weitere Fakten oder Ideen werden gern genommen.

An dieser Stelle möchte ich mich nochmal ehrlich bei @lisanet entschuldigen, die sich wirklich grösste Mühe gegeben hat, und ich war am Ende zT ziemlich unfair. Ich kann nur sagen, dass das dem langen Tag geschuldet und ich recht frustriert war.

 

[lisanet]

meine Vermutung: weil sie rsync selbst kompiliert und die binary immer unter /usr/local/bin liegt - sich der Pfad also nie ändert.

das ist für mich die plausibelste Erklärung und ergäbe Sinn.

Wer lust hat kann ja mal die developer Doku zu launchd durch forsten, ob da was zu der Art wie lauchnd einmal geladene binaries handhabt / verwaltet / cached / mit Berechtigungen versieht (das dürfte hier der Fall sein)

 

[lisanet]

homebrew ca. 500kb groß ist, wärend der selbstkompilierte ca. 5MB hat - also offensichtlich anders kompiliert ist

dynamic vs static linking

 

[MOM2006]

Offene Fragen:
- Warum funktioniert das mit Homebrew rsync nicht "einfach" so im Zusammenhang mit LaunchAgent?
--> meine Vermutung: die rsync binary von homebrew liegt, wenn sie aktualisiert wird, in einem neuen Verzeichnis (in diesem Fall /..../3.4.1/ ) und muss daher unter macOS zur Ausführung im LaunchAgent neu "registriert" werden
- Warum funktioniert der update bei anderen zB @lisanet problemlos (manuell startend wie automatisch über LaunchAgent)?
--> meine Vermutung: weil sie rsync selbst kompiliert und die binary immer unter /usr/local/bin liegt - sich der Pfad also nie ändert.

dann stellt sich die frage ob es nicht angebracht wäre unster /usr/local/bin einen rsync symlink zu machen, der dann halt immer auf das aktuelle rsync im jeweiligen homebrew verzeichnis verweist. vielleicht schluckt das der LaunchAgent ja so dann.

 

[OmarDLittle]

Also am Ende kann man sagen, es handelt sich um irgendeine Eigenheit von MacOS, man weiß nicht welche, man weiß nicht wie man es reproduzierbar und zuverlässig beheben kann, und kann quasi nur hoffen, dass man irgendeine "Registrierung" neu auslöst, wenn man das Binary in einen anderen Pfad verschiebt.

Das ist für mich dann schon eher wieder eine typische schwachsinnige Apple-Eigenheit bei MacOS, und nichts wo der Anwender vorbeugen oder sich auskennen kann.

 

[MrChad]

@jteschner

dynamic vs static linking

In meinen Worten (ohne es im Detail untersucht zu haben)

• wenn das rsync von homebrew laufen will, dann sucht es sich irgendwo unter .../lib/... sogenannte libraries dazu, die es für die Ausführung braucht. (in Windows-speak als "DLL" bekannt)
• das selbstgemachte rsync hat das alles fest in seinem Binary schon drinne.

Der automatisch vorgeschaltete brew update / brew upgrade hat bei der Installation irgendwelche dieser libraries ausgetauscht, welche dann in der neuen Version nachgeladen wurden und letztendlich das Problem verursacht haben.

Will sagen:

• Es genügt nicht, nur die rsync-Datei und deren Pfad oder Speicherort zu betrachten und zu vergleichen
• Um die ganzen Details der dynamisch nachgeladenen Libraries herauszufinden, müsstest du ganz genau nachschauen, welche (u.a. in .../lib/... ) da mitspielen und welche da neulich gerade mal geändert wurden.

Lernerfahrung:

• So nett und einfach so Sachen wie homebrew auch erscheinen mögen,
• So ganz und gar unproblematisch und fool-proof sind sie am Ende des Tages dann doch wieder nicht ...

 

[MOM2006]

Lernerfahrung:

• So nett und einfach so Sachen wie homebrew auch erscheinen mögen,
• So ganz und gar unproblematisch und fool-proof sind sie am Ende des Tages dann doch wieder nicht ...

Weil scheinbar Apple wieder mal mit irgendwas "gegen pfuscht". Wenn Pfade und Lib Pfade und alles korrekt definiert sind, dann ist das auf jedem unix kein Problem. Nur halt scheinbar nicht auf Apple Platform, weil irgendein Layer, den keiner so wirklich kennt, dazwischen wieder quer schlägt.

 

[jteschner]

dann stellt sich die frage ob es nicht angebracht wäre unster /usr/local/bin einen rsync symlink zu machen, der dann halt immer auf das aktuelle rsync im jeweiligen homebrew verzeichnis verweist. vielleicht schluckt das der LaunchAgent ja so dann.

Ohne es getestet zu haben, vermute ich, dass das auch nicht geht.
Grund: auch aktuell in Homebrew ist rsync nur verlinkt.
In /opt/homebrew/bin befinden sich nur Links auf die "echten" binaries, die sich in verschiedenen Ordnern verteilt im "Cellar" befinden. Und in diesem Cellar ändern sich die Ordner gemäß Versionsnummer bei einem Update und ebenso natürlich die links dahin.

Und da offensichtlich die unterschiedlichen Environments zwischen Terminal und LaunchAgent, der oder ein Grund für die unterschiedlichen Verhaltensweisen in der Ausführung sind, wird sich durch einen Link nichts ändern.

Für mich ist eher die Frage, ob sich nicht im LaunchAgent das Environment ändern lässt, unter dem die Programme/Scripte ausgeführt werden.
Dann wäre das Problem ursächlich beseitigt ...

 

[MOM2006]

Ohne es getestet zu haben, vermute ich, dass das auch nicht geht.
Grund: auch aktuell in Homebrew ist rsync nur verlinkt.
In /opt/homebrew/bin befinden sich nur Links auf die "echten" binaries, die sich in verschiedenen Ordnern verteilt im "Cellar" befinden. Und in diesem Cellar ändern sich die Ordner gemäß Versionsnummer bei einem Update und ebenso natürlich die links dahin.

Und da offensichtlich die unterschiedlichen Environments zwischen Terminal und LaunchAgent, der oder ein Grund für die unterschiedlichen Verhaltensweisen in der Ausführung sind, wird sich durch einen Link nichts ändern.

Für mich ist eher die Frage, ob sich nicht im LaunchAgent das Environment ändern lässt, unter dem die Programme/Scripte ausgeführt werden.
Dann wäre das Problem ursächlich beseitigt ...

ehm warum definierst du dann nicht $PATH $LIB Pfade oder was auch immer in deinem script welches der LaunchAgent dann ausführen soll? lass dir halt die jeweiligen Umgebungsvariablen am Terminal ausgeben von dem user wo es funktioniert und setz die dann im Script. Ist vielleicht Overkill, aber vielleicht hilft es auch.

 

[MrChad]

Weil

• An irgendwelchen Schuldzuweisungen möchte ich mich ausdrücklich NICHT beteiligen.
• Weder die eine noch die andere.

 

[jteschner]

ehm warum definierst du dann nicht $PATH $LIB Pfade oder was auch immer in deinem script welches der LaunchAgent dann ausführen soll? lass dir halt die jeweiligen Umgebungsvariablen am Terminal ausgeben von dem user wo es funktioniert und setz die dann im Script. Ist vielleicht Overkill, aber vielleicht hilft es auch.

Ich schau mir das mal an.
Allerdings kann man auch im LaunchAgent ENV-Variablen setzen ... (habe ich gerade in der Doku gelesen)

Ich werde mir mal die genauen Unterschiede im ENV anschauen und schauen, was ich tue.

 

[jteschner]

Gesagt, getan:
Die auffälligsten Unterschiede, die ich erkennen kann (und die ggf. entscheidend für die Ausführung sein könnten):
- PATH --> bei Terminal weitaus umfangreicher
- SHLVL --> Terminal: 2 , LaunchAgent: 1

Ansonsten: sehr viel Gleiches

Bei Terminal-Ausführung gibt es noch ein paar mehr Variablen, die aufgeführt sind, aber so was wie TERM, TERM_PROGRAM, INFOPATH, MANPATH, PROMPT, ... kann man wohl aussen vor lassen - denke ich.

Wobei SHLVL meines Erachtens eher keine Rolle spielen sollte (wenn ich so die Doku dazu anschaue)...

 

[Difool]

In /opt/homebrew/bin befinden sich nur Links auf die "echten" binaries, die sich in verschiedenen Ordnern verteilt im "Cellar" befinden. Und in diesem Cellar ändern sich die Ordner gemäß Versionsnummer bei einem Update und ebenso natürlich die links dahin.

Hier kurz ein Stop, denn:
„… a formula is keg-only if it is not symlinked into Homebrew’s prefix“

What does “keg-only” mean?

It means the formula is installed only into the Cellar and is not linked into the default prefix. This means most tools will not find it. You can see why a formula was installed as keg-only, and instructions for including it in your PATH, by running brew info <formula>.

You can modify a tool’s build configuration to find keg-only dependencies. Or, you can link in the formula if you need to with brew link <formula>, though this can cause unexpected behaviour if you are shadowing macOS software.

Quelle: https://docs.brew.sh/FAQ#what-does-keg-only-mean

Ein kurzes Abfragen mit brew info rsync sollte Aufschluß über deinen Pfad dort geben, ob im /opt/homebrew/Cellar/ ….
Bzw. liegen „im Cellar“ erst die Namens-Verzeichnisse und darin die Version:
/opt/homebrew/Cellar/ffmpeg/7.1_4 …

Und ich würde dem Chad da auch zustimmen:

Will sagen:

• Es genügt nicht, nur die rsync-Datei und deren Pfad oder Speicherort zu betrachten und zu vergleichen
• Um die ganzen Details der dynamisch nachgeladenen Libraries herauszufinden, müsstest du ganz genau nachschauen, welche (u.a. in .../lib/... ) da mitspielen und welche da neulich gerade mal geändert wurden.

Ein update aktualisiert auch weitere in Abhängigkeit mitlaufende Packages.
Siehe auch: https://docs.brew.sh/FAQ#why-does-brew-upgrade-formula-or-brew-install-formula-also-upgrade-a-bunch-of-other-stuff

 

[jteschner]

Hier kurz ein Stop, denn:
„… a formula is keg-only if it is not symlinked into Homebrew’s prefix“

Quelle: https://docs.brew.sh/FAQ#what-does-keg-only-mean

Ein kurzes Abfragen mit brew info rsync sollte Aufschluß über deinen Pfad dort geben, ob im /opt/homebrew/Cellar/ ….
Bzw. liegen „im Cellar“ erst die Namens-Verzeichnisse und darin die Version:
/opt/homebrew/Cellar/ffmpeg/7.1_4 …

Und ich würde dem Chad da auch zustimmen:

Ein update aktualisiert auch weitere in Abhängigkeit mitlaufende Packages.
Siehe auch: https://docs.brew.sh/FAQ#why-does-b...l-formula-also-upgrade-a-bunch-of-other-stuff

Wenn ich ehrlich bin, muss ich sagen, dass mir das nun leider etwas zu kompliziert wird.
Im Moment würde ich sagen, dass ich lieber mit dem selbst-kompilierten rsync in /usr/local/bin lebe und bei Bedarf update. Funktioniert ja - und nun auch mit LaunchAgent.
Homebrew funktioniert ja gut und einfach - so lange man die Tools nicht mit LaunchAgents verwenden will.
Und rsync ist zZt das einzige Tool, das ich so verwende.
Alles andere verwende ich direkt im Terminal.

Aber wenn es eine einfache bekannte Lösung mit Homebrew/LaunchAgent gibt, werde ich sie gern testen/verwenden.

 

[jteschner]

Kurzer Status: nun laufen beide rsync (/usr/local/bin/rsync und /opt/homebrew/bin/rsync) über LaunchAgent
Erklären warum tatsächlich, kann ich das nicht, aber ich schreibe kurz, was ich getan habe:

- in den Einstellungen "Festplattenvollzugriff" habe ich 2 Einträge zum "rsync", die sich nicht mehr im Finder anzeigen lassen, entfernt. Übrig blieb der /usr/local/bin/rsync
- dann nochmal einen neuen LaunchAgent erstellt mit dem Executable

/bin/sh -c "/opt/homebrew/bin/rsync -av --iconv=utf-8-mac --exclude=.DS_Store /Users/jt/Documents/ jt@omv.local::dokumente/Documents"

- es kam dann beim "Load" des LaunchAgent die obligatorische Frage nach dem "Festplattenvollzugriff", die ich bestätigt habe
- nach zweimal starten lief der LaunchAgent dann erfolgreich durch
- dann nochmal ein Test LaunchAgent mit Backup-Script, das /opt/homebrew/bin/rsync ...... enthält
--> läuft
- und ein Test LaunchAgent mit Backup-Script /usr/local/bin/rsync
--> läuft

Ich vermute, dass es mit der Neu-Registrierung im System zum "Festplattenvollzugriff" zu tun hat, die dann auch irgendwie den Netzwerkzugriff mit freischaltet o.ä.

Wer das erklären kann: Feuer frei ;-)

 

[MOM2006]

Wer das erklären kann: Feuer frei ;-)

Apple vielleicht. Vielleicht auch ein Bug. Ist ja nicht so, dass vieles was von Apple kommt keine Berechtigungen braucht, dann aber vielleicht doch wieder Berechtigungen braucht. Das System vor allem in MacOS Sequoia stinkt, auch wenn das einige nicht wahrhaben wollen. Ich hab genug gesehen und getestet um mir ein Urteil darüber erlauben zu können.

 

[Difool]

@MOM2006
Du könntest langsam bitte einmal deine „Polemik“ in anderer Leute Threads sein lassen.
Es ermüdet bisweilen etwas und trägt wirklich nicht zum Thema bei, da es immer subjektiv ist.

 

[Difool]

Ich vermute, dass es mit der Neu-Registrierung im System zum "Festplattenvollzugriff" zu tun hat, die dann auch irgendwie den Netzwerkzugriff mit freischaltet o.ä.

Ist zwar heise, aber lies trotzdem mal diesen Artikel dazu:
https://www.heise.de/news/macOS-Festplattenvollzugriff-des-Terminals-koennen-andere-Apps-missbrauchen-7282104.html

 

[MrChad]

diesen Artikel dazu

ist doch Quatsch.

1. ist der Text von 2022
2. ist das ziemlich logisch. Wenn ich Terminal den "Festplattenzugriff" erlaube, dann haben die Programme darin zur großen Überraschung auch: "Festplattenzugriff" - oh, Wunder.
3. Läuft sein Skript im Normalbetrieb gar nicht unter "Terminal".

Richtig ist, dass vielfach so etwas geraten wird, obwohl es nur am Symptom herumdoktort.

 

[lisanet]

Wer das erklären kann: Feuer frei ;-)

hier ein Ausgangspunkt für Recherchen: Doku zu launchd -> https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/CreatingLaunchdJobs.html

Damit wird das m.E. zusammen hängen. Auch wenn die bekannten Hater wieder mal meinen es sei ein bug, nur weil sie selbst keinerlei Ahnung von Betriebssystemen, moderner Prozessverwaltung und Co haben.

Wer Lust hat, kann anhand der o.g. Doku mal anfangen, sich in die Materie einzuarbeiten.

Da hier ja schon wieder Hater auftauchen, habe ich einfach keinen Bock, das selbst zu machen, nur um von diesen Typen das übliche gebashe zu hören.