Ubuntu 24.04 Cronjob - aws Befehl/Script

[user_xy]

Nabend,

keine Ahnung, vielleicht ist ja nen Linux Cr4ck unterwegs und hat ne Antwort parat...

Situation ist folgende:

• VPS mit Ubuntu 24.04 per do-release-upgrade von 22.04 auf 24.04 gebracht.
• Anfragen während Upgrade Prozess für Änderung der diversen Config Files dazu bewegt die original Config Files zu behalten, und nix zu ersetzen.
• gab einige Probleme zu fixen was zb. SQL Server (nachträglicher upgrade Befehl) oder Webserver und PHP 8.1 zu 8.3 Anpassung bedurfte inkl Nacheintragung diverser Repositorys und Neuinstalltionen zb. awscli was hier ne Rolle spielt und noch einiges mehr, alles gefixt bekommen soweit.

Administriere das meiste über Webmin, auch Cron, jaja einige werden jetzt schimpfen, ich mags und finds seit den ersten Tagen aus ca. 2001 echt klasse, trotzdem geht auch viel über Konsole und iss kein Problem für mich soweit.

Hatte unter Ubuntu 22.04 meine Scripte vor dem Upgrade, unter anderem auch die awscli Scripte, erfolgreich laufenlassen können über Cron, nur jetzt zickt das ganze iwie und Cron weigert sich standhaft die Dinger auszuführen.


Wenn ich das Script über Konsole mit:

dude@machine:~$ /pfad/zu/script/script.sh

laufen lasse iss alles in Butter, oder lasse ich den Befehl aus dem Script direkt über die Konsole anlaufen

dude@machine:~$ aws --profile Profilname --region default --endpoint-url https://domain.com s3 sync --delete /pfad/zu/ordner/ s3://pfad/zu/ordner/

iss alles gut soweit.


Nur will Cron weder das Script noch den direkten Befehl annehmen ohne mir:

/pfad/zu/script/script.sh: line x: aws: command not found
oder
/bin/sh: 1: aws: not found

zu melden.


Wie gesagt, vor dem do-release-upgrade lief Cron mit den Scripts ohne Probleme!

Meine Vermutung ist das für Cron evtl. explizit ne Systemvariable für aws gesetzt werden muss? Keine Ahnung, kann auch nix diesbzgl. finden was mir weiterhilft.

Wie gesagt, in der Konsole funktioniert das Script oder der aws Befehl direkt Problemlos, nur Cron zickt iwie rum.


Achso, awscli hab ich mit:

dude@machine:~$ curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
dude@machine:~$ unzip awscliv2.zip
dude@machine:~$ sudo ./aws/install --bin-dir /usr/local/bin --install-dir /usr/local/aws-cli --update
dude@machine:~$ sudo aws configure --profile Profilname

Das ging vorher direkt aus dem Ubuntu 22.04 Repository heraus, doch in Ubuntu 24.04 hab ich nur damit meine aws befehle zum laufen gebracht, naja zumindest im Terminal, nur über Cron zickt das ganze halt wie erwähnt.

Ein Check mit aws --version iss auch erfolgreich, wie gesagt in der Konsole funktionierts.

dude@machine:~$ aws --version
aws-cli/2.17.42 Python/3.11.9 Linux/6.8.0-41-generic exe/x86_64.ubuntu.24


Also, wenn jemand ne Lösung parat hat, immer her damit denn ich bin langsam am Ende mit meinem Latein

 

[oicfar]

Ich nix aws, aber ich würde denken, dass

• aws command ist nicht im PATH, welches in der Crontab-Session gestartet wird

Ich würde es so testen: which aws
Und dann in crontab ein Eintrag machen mit echo $PATH > ~/crontab_path.txt. Und dann schauen, ob der PFAD für aws in der Ausgabe drin ist.

Oder in crotab /path/aws ... eintragen.

 

[user_xy]

Danke für deine Antwort.


Ein "which aws" ergibt:

/usr/local/bin/aws


Wenn du mir jetzt noch sagst in welcher Datei ich welchen Eintrag machen sollte, wäre ich dir sehr dankbar.

 

[oicfar]

Und wenn du ein Crontab Eintrag mit

* echo $PATH > ~/crontab_path.txt

anlegst. Was steht dann in ~/crontab_path.txt

Wenn du in crontab statt

aws --profile Profilname --region default --endpoint-url https://domain.com s3 sync --delete /pfad/zu/ordner/ s3://pfad/zu/ordner/

das

/usr/local/bin/aws --profile Profilname --region default --endpoint-url https://domain.com s3 sync --delete /pfad/zu/ordner/ s3://pfad/zu/ordner/

einträgst, geht es?

 

[JumpingCat]

In deinem Skript: Shebang ist korrekt gesetzt? Gerade Ubuntu ist da kreativ.

Versuche es mit
#!/bin/bash --login

oder was auch immer which bash als Ausgabe hat.

Ansonsten an den Anfang nach der Shebang:

export PATH="/usr/local/bin:${PATH}"


PS: Wieso fehlen hier am Smartphone alle Buttons für Zitat, etc und native BB-Code auch?

 

[oicfar]

PS: Wieso fehlen hier am Smartphone alle Buttons für Zitat, etc und native BB-Code auch?

Hate auch schon gestern gesehen. Dachte, dass das was bei mir vielleicht sein könnte. Sieht wohl so aus, dass es hier ein Problem gibt.

 

[user_xy]

Saubär

/usr/local/bin/aws im Script hat geholfen.

Im alten Script hat aws gereicht. Danke.


In nem anderen alten "Script" mit rclone wurde auch mit /usr/local/bin/aws angefeuert...

Hätt ich eigentlich auch selber drauf kommen können...


Kann doch sicher nen Systemweiten Eintrag machen das ich /usr/local/bin/aws nicht mehr brauche?

 

[oicfar]

Saubär

Jut.

Im alten Script hat aws gereicht. Danke.

Da ist halt in der Cron-Session /usr/local/bin nicht im PATH.

Hätt ich eigentlich auch selber drauf kommen können...


Kann doch sicher nen Systemweiten Eintrag machen das ich /usr/local/bin/aws nicht mehr brauche?

Wie ist der Satz gemeint?

 

[user_xy]

Wie ist der Satz gemeint?

Naja, das ich im Script für Cron nicht mehr /usr/local/bin/aws angeben muss sondern aws reicht.

Dem System quasi mitteilen das /usr/local/bin/aws gleich aws ist

Oder muss das jetzt wirklich wie vermutet für Cron explizit angegeben werden, denn im terminal funktioniert aws ja ohne /usr/local/bin/aws.

Meine fresse, ich machs aber auch kompliziert

 

[oicfar]

Du kannst es auch wie in #5 steht. Halt im Script vor der aws Zeile das

export PATH="/usr/local/bin:${PATH}"

hinzufügen. Und dann wird auch aws.

 

[GaborDenes]

die Scripte aus cron werden nicht mit dem einloggten User ausgeführt, sondern mit dem Systemuser (dürfte root sein), der einen anderen Wert für path$ verwendet.
Deswegen habe ich mir angewöhnt, in crontab immer vollständige Pfadangaben für auszuführende Dateien anzugeben, dann scheitert's zumindest nicht daran.

 

[oicfar]

Ich hab's bei mir unter Ubuntu 24.04 kurz getestet:
crobtab Eintrag für den Nutzer egon:

* * * * * whoami >> /tmp/cron.txt && echo $PATH >> /tmp/cron.txt

Und der Eintrag in /tmp/cron.txt lautet:

egon
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin

 

[sh.]

PS: Wieso fehlen hier am Smartphone alle Buttons für Zitat, etc und native BB-Code auch?

schonmal die 3 Punkte geklickt?

 

[user_xy]

Okay, Danke.

Ich belasse es beim vollen Pfad in den Script Dateien, iss dann auch okay


Keine Ahnung warum Cron da ne Extrabehandlung braucht... Ohne Worte... Läuft...

Die Scripte in Cron sollen in meinem Fall tatsächlich als root ausgeführt werden.

Auch wenns doof klingt, in der Konsole hatte ich als fakeroot mit sudo oder normaler user keine Probleme ohne direkten Pfad den aws Befehl auszuführen, mit root hatte ich es nicht probiert, war ja vor dem upgrade auch kein Problem und ich hatte an den Permissions nichts geändert, nur Cron meinte da jetzt rumzickn zu müssen

 

[oicfar]

@sh. welche Punkte? Wenn ich auf dein Post auf dem Smartphone "Zitat" klicke, sieht es dann so aus

Auf dem Smartphone kann ich nicht mal Text eingeben. gestern ist mir das aufgefallen. Und auf dem Smartphone blocke ich nichts. Getestet auch mit mobiler Verbindung.

 

[sh.]

@oicfar

 

[oicfar]

Also an Hell oder Dark liegt's nicht bei mir. Ich sehe es mir morgen genauer an, was Sache ist.

 

[netzgestaltung]

Keine Ahnung warum Cron da ne Extrabehandlung braucht...

Vielleicht läuft der als anderer Benutzer? Dann hätte der eine eigene .bashrc

 

[nutrix]

Keine Ahnung warum Cron da ne Extrabehandlung braucht... Ohne Worte... Läuft...

Cron ist nur ein Fork eines Userprozesses ohne Umgebung (.profile wie .bash_rc ziehen nicht, die gelten nur für Logins), so wie systemd. Man muß jedem Cronjob, wie bei systemd, die komplette Umgebung zur Laufzeit mitgeben und erzeugen, so wie Pfade.

 

[user_xy]

@nutrix Für die Zukunft hab ichs mir schon hinter die Ohren geschrieben

Ich sag es trotzdem nochmal, vor dem Upgrade von Ubuntu 22.04 auf 24.04 hatte ich das Problem nicht und konnte Cron mit aws statt dem ganzen Pfad /usr/local/bin/aws füttern.

Da hat er nicht rumgezickt und das lief.