Forum: Mikrocontroller und Digitale Elektronik benötige Hilfe bei bash-script per cronjob

Der Cron Scheduler läuft mit anderen Umgebungsvariablen, als eine 
interaktive root Sitzung. Du könntest sue mit dem env Befel ausgeben und 
vergleichen. Vielleicht scheitert es ganz banal am PATH.

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