benötige Hilfe bei bash-script per cronjob

Hans M. schrieb:

Ich habe das script in die crontab eingetragen. Es wird auch zum richtigen Zeitpunkt aufgerufen, bricht aber immer mit dem Fehler: "[#] sysctl -q net.ipv4.conf.all.src_valid_mark=1 /usr/bin/wg-quick: line 32: sysctl: command not found" ab.

Klingt nach falschem Suchpfad. Fehlt /sbin?

Hans M. schrieb:

sysctl: command not found"

sysctl ist im (/usr)/sbin Verzeichnis, nicht (/usr)/bin. Also für Nicht-Root nicht im Pfad, für cron evtl. auch nicht, wenn die crontab das nicht per PATH=... definiert.

Also: Einfach im script den vollen Pfad zu sysctl angeben.

Εrnst B. schrieb:

Hans M. schrieb:

sysctl: command not found"

sysctl ist im (/usr)/sbin Verzeichnis, nicht (/usr)/bin. Also für Nicht-Root nicht im Pfad, für cron evtl. auch nicht, wenn die crontab das nicht per PATH=... definiert.

Also: Einfach im script den vollen Pfad zu sysctl angeben.

Hallo Zusammen!

Vielen Dank für die ersten Meldungen. ich habe jetzt folgendes gemacht:

In der Konsole geprüft: nasathome:~ # which sysctl /sbin/sysctl

habe in mein script folgendes eingetragen: PATH=$PATH:/sbin/ export PATH

und nochmals mittels webmin den cronjob gestartet Ergebnis: die gleiche Fehlermeldung erscheint.

Also der Pfad war es wohl schonmal nicht :-(

Hans M. schrieb:

,,, wenn ich es als root in der Konsole unter bash direkt starte.

Hat "root" keine eigene crontab? Evtl. braucht dein Script tatsaechlich root-Rechte. Da huelft ein Patheintrag dann natuerlich ueberhaupt nicht.

das script wird als root gestartet. siehe Bild.

Hans M. schrieb:

das script wird als root gestartet. siehe Bild.

Dann solltest du mit einem "whoami >/tmp/blablupp;set >>/tmp/blablupp" im script einmal kontrollieren was da gespielt wird.

anbei die Ausgaben von whoami und set

Das sieht mir eher nach "direkt eingetippt und gestartet" als nach crontabjob aus.

Wenn alles richtig ist, muss es ja funktionieren.

tut es eben nicht!

sonst würde ich hier nicht um Hilfe bitten!

Wird das Programm in der systemübergreifenden Crontab -> /etc/crontab oder einer benutzereigenen Crontab gestartet?

Zeig mal Deine Datei /etc/crontab als Code

Hemm, ein sbin steht im Pfad und er findet sysctl nicht. Da findet er dann wohl ein passendes ld-linux.so.* nicht. Warum auch immer. Ein /sbin/sysctl sollte dann auch einen Fehler erzeugen. Der LD_LIBRARY_PATH ist auch "leer". Ob das in deiner Umgebung richtig ist, kann ich dir nicht sagen. Du solltest es aber in einer interaktiven shell pruefen.

und zeig mal bitte das Ergebnis von

1

ls -la /usr/bin/wg-quick

das script wird gestartet aus der root crontab unter /var/spool/cron/tabs/root

anbei das Ergebnis von ls -la /usr/bin/wq-quick

/sbin/sysctl findet er siehe Bild

Hans M. schrieb:

/sbin/sysctl findet er siehe Bild

Dann schreib das doch auch einfach so in dein Skript.

probier mal in der crontab statt

1

bash ...

-->

1

/bin/bash ...

oder

1

/usr/bin/bash ...

ausprobiert!

keine Änderung

also, das hat das ganze etwas vorangebracht!!!! DER SYSCTL Fehler ist überwunden, dafür ist jetzt der nächste Fehler da...

dafür ist jetzt der nächste Fehler da...

Du solltest jetzt selber wissen wie du den beheben kannst. :)

MotoPick!

Super vielen Dank! das war der richtige Hinweis! Jetzt läuft alles perfekt!

Ich habe in der /usr/bin/wq-quick vor die Befehle sysctl und iptables-restore den jeweils richtigen absoluten Pfad geschrieben. also /sbin/sysctl und /usr/sbin/iptables-restore und schon werden die Befehle gefunden!

Nochmals RIESENDANK für die Hilfen von Euch allen!!!

Trotzdem ist unklar, warum trotz der Pfade in der Umgebungsvariable die Befehle nicht gefunden werden....

Hans M. schrieb:

Trotzdem ist unklar, warum trotz der Pfade in der Umgebungsvariable die Befehle nicht gefunden werden....

PATH=$PATH:/sbin/ export PATH

Weil die Shell die neuen Kommandos unter /sbin noch nicht kennt.

Das naechste Mal also besser so:

PATH=/sbin:$PATH export PATH hash -r

...wieder was gelernt "hash -" kannte ich noch nicht

ich habe dafür immer "history" verwendet

Hans M. schrieb:

...wieder was gelernt "hash -" kannte ich noch nicht

ich habe dafür immer "history" verwendet

hash -r hat mit history genau nichts zu tun. Es gibt noch viel zu lesen.

oh ja, und das werde ich auch tun! habe halt doch nur ein gesundes Halbwissen :-|

Hans M. schrieb:

habe in mein script folgendes eingetragen: PATH=$PATH:/sbin/ export PATH

Irgendwie sieht der "/" am Ende komisch aus. Mal weglassen.

Also ich habe den "hash -r" eigentlich noch nie benutzen müssen, selbst wenn ich in einem Shellskript den PATH verändert habe. Also gerade auch in cron scripts hat es immer so funktioniert.

Und so auch in diesem einfachen Beispiel:

1

[root@acme blub]# crontab -l

2

* * * * * /root/blub/bla.sh

3

[root@acme blub]# cat bla.sh

4

#!/bin/sh

5

exec >/tmp/debug.txt 2>&1

6

set -x

7

mytest

8

export PATH=$PATH:/root/blub

9

mytest

10

[root@acme blub]# cat mytest

11

#!/bin/sh

12

echo "hallo!"

13

[root@acme blub]# cat /tmp/debug.txt

14

+ mytest

15

/root/blub/bla.sh: line 4: mytest: command not found

16

+ export PATH=/usr/bin:/bin:/root/blub

17

+ PATH=/usr/bin:/bin:/root/blub

18

+ mytest

19

hallo!

Anderes Thema... Dir ist bekannt, dass rsync verschlüsselt über ssh arbeitet und man da einfach nur einen offenen SSH-Server braucht und nicht mit wireguead usw. Umwege machen muss?

rsync -av /some/src/dir/ user@remotemachine:/some/path/to/go/

Baut automatisch einen SSH Tunnel auf remotemachine auf, startet dort einen rsync Server, erledigt die Arbeit, stoppt den rsync Server und schließt die ssh-Session.

Markus M. schrieb:

Und so auch in diesem einfachen Beispiel:

Wie du am einfachen Beispiel des TO gesehen hast, war es bei ihm wohl erforderlich. Noetig ist es allgemein immer dann, wenn $PATH geaendert wurde, und die Shell die Liste der darueber ausfuehrbaren Kommandos aktualisieren muss. Es reicht z.B. auch, ein Binary in ein Verzeichnis zu kopieren, dass Bestandteil von $PATH ist. Auch das wuerde nicht gefunden. Also nicht nur in Cronjobs.

Du kannst derweil ja herausfinden, warum es bei dir ohne "hash -r" funktioniert.

Peter D. schrieb:

Anderes Thema... Dir ist bekannt, dass rsync verschlüsselt über ssh arbeitet und man da einfach nur einen offenen SSH-Server braucht und nicht mit wireguead usw. Umwege machen muss?

rsync -av /some/src/dir/ user@remotemachine:/some/path/to/go/

Baut automatisch einen SSH Tunnel auf remotemachine auf, startet dort einen rsync Server, erledigt die Arbeit, stoppt den rsync Server und schließt die ssh-Session.

...nein, das war mir so nicht bekannt. Und so macht man (hier: ich) aus Unwissenheit über Jahre eben was falsch...

Hans M. schrieb:

rsync -av /some/src/dir/ user@remotemachine:/some/path/to/go/

Nee, das muss so aussehen (-e gibt die remote shell an):

1

rsync -av -e ssh /some/src/dir/ user@remotemachine:/some/path/to/go/

sonst wäre das unverschlüsselt