Debian11 - Bash Script per Autostart ausführen
Morgen Zusammen,
ich habe die OS Debian11 aufgespielt und möchte nun dass eine Bash-Skript beim Start geladen wird, das passiert aber nicht.
Egal ob ich das Ganze als root oder als user ausführe, es tut sich einfach nichts, im Protokoll gibt es auch keine Fehlermeldung.
Die Startausführung habe ich so vorgenommen:
die jeweilige "start.sh" fängt mit "#!/bin/sh" an, funktioniert auch wenn diese manuell übers Terminal ausgeführt wird.
Gibt es in der Debian 11 Distro irgendwas zu beachten was mit crontab zutun hat?
Danke und schönes Wochenende!
ich habe die OS Debian11 aufgespielt und möchte nun dass eine Bash-Skript beim Start geladen wird, das passiert aber nicht.
Egal ob ich das Ganze als root oder als user ausführe, es tut sich einfach nichts, im Protokoll gibt es auch keine Fehlermeldung.
Die Startausführung habe ich so vorgenommen:
crontab -e
@reboot /home/user/start.sh
die jeweilige "start.sh" fängt mit "#!/bin/sh" an, funktioniert auch wenn diese manuell übers Terminal ausgeführt wird.
Gibt es in der Debian 11 Distro irgendwas zu beachten was mit crontab zutun hat?
Danke und schönes Wochenende!
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 3976782182
Url: https://administrator.de/contentid/3976782182
Ausgedruckt am: 22.11.2024 um 05:11 Uhr
6 Kommentare
Neuester Kommentar
Cron Jobs haben die Eigenschaft, dass sie ggf. nicht "wissen", wo sie ein binary finden.
Deswegen sollte man innerhalb eines Scriptes, welches per Cronjob ausführt, im Zweifelsfall immer den FULL path eines commands angeben.
Also zB "/usr/sbin/iptables" anstatt von nur "iptables".
Elegant lösen kann man das mit Variablen für die commands, innerhalb des Scripts, zB:
und dann im weiteren Verlauf eben nur noch mit der Variable IPTABLES arbeiten.
Alternativ könntest du die PATH Variable der crontab erweitern, siehe zB hier:
https://unix.stackexchange.com/a/148137
-> allerdings hat es seinen Grund, weswegen zwischen user- und system-crontabs unterschieden wird.
Ansonsten: Was macht denn das Script? Kannst ja sonst mal hier reinstellen, oder ist es "geheim"? ;)
Deswegen sollte man innerhalb eines Scriptes, welches per Cronjob ausführt, im Zweifelsfall immer den FULL path eines commands angeben.
Also zB "/usr/sbin/iptables" anstatt von nur "iptables".
Elegant lösen kann man das mit Variablen für die commands, innerhalb des Scripts, zB:
IPTABLES=$(which iptables)
Alternativ könntest du die PATH Variable der crontab erweitern, siehe zB hier:
https://unix.stackexchange.com/a/148137
-> allerdings hat es seinen Grund, weswegen zwischen user- und system-crontabs unterschieden wird.
Ansonsten: Was macht denn das Script? Kannst ja sonst mal hier reinstellen, oder ist es "geheim"? ;)
Nein, es geht um die sog. PATH Variable, die ist generell dafür da, dass dein System (bzw. zB deine bash) "weiß", wo sie nach binaries suchen soll.
(Es gibt auch sog. built-in commands, die sind dann quasi bei der Shell schon mit bei, aber das sind eher wenige.)
Gib einfach mal ein, also in deiner Shell:
-> Das sind all die Stellen / Verzeichnisse, wo deine Shell nach binaries sucht, wenn sie ein command ausführen soll.
Das, was du meinst, ist der Pfad zu deinem Script - da muss genau das als Pfad hin, wo das Script eben liegt.
Tatsächlich ist das "user" dabei etwas.. komisch. Es sei denn, du hast einen User, der tatsächlich "user" heißt (?)
Wo liegt das Script denn, also der exakte, volle Dateipfad?
Mit dem "which" command kannst du rausfinden, wo das binary des entspr. commands "wirklich" sitzt, also zB:
-> /usr/bin/echo
Deshalb sollte man - innerhalb eines Scripts - im Zweifelsfall eben nicht "echo" schreiben, sondern "/usr/bin/echo", wenn man das mit einem Cronjob verwenden möchte.
Alternativ löst man das Ganze durch eine Variable, s.o.
(Es gibt auch sog. built-in commands, die sind dann quasi bei der Shell schon mit bei, aber das sind eher wenige.)
Gib einfach mal ein, also in deiner Shell:
echo $PATH
Das, was du meinst, ist der Pfad zu deinem Script - da muss genau das als Pfad hin, wo das Script eben liegt.
Tatsächlich ist das "user" dabei etwas.. komisch. Es sei denn, du hast einen User, der tatsächlich "user" heißt (?)
Wo liegt das Script denn, also der exakte, volle Dateipfad?
Mit dem "which" command kannst du rausfinden, wo das binary des entspr. commands "wirklich" sitzt, also zB:
which echo
Deshalb sollte man - innerhalb eines Scripts - im Zweifelsfall eben nicht "echo" schreiben, sondern "/usr/bin/echo", wenn man das mit einem Cronjob verwenden möchte.
Alternativ löst man das Ganze durch eine Variable, s.o.
Dann schau vielleicht erstmal, ob der Cronjob bei (re)boot überhaupt stattfindet.
Schreib etwas Simples wie
@reboot echo "cron test" >> /home/user/cron_test.txt
in dein Crontab, dann reboote und sieh nach, ob der Text in der Datei steht.
In deinem Syslog sollte auch so etwas auftauchen:
(CRON) INFO (Running @reboot jobs)
Wenn das funktioniert, dann kann man das Ganze in ein Script schreiben, und dieses dann @reboot laufen lassen.
Funktioniert dies auch, weißt du ziemlich sicher, dass es am Inhalt deines ursprünglichen Scripts liegt, und nicht an den cron Mechanismen.
Schreib etwas Simples wie
@reboot echo "cron test" >> /home/user/cron_test.txt
in dein Crontab, dann reboote und sieh nach, ob der Text in der Datei steht.
In deinem Syslog sollte auch so etwas auftauchen:
(CRON) INFO (Running @reboot jobs)
Wenn das funktioniert, dann kann man das Ganze in ein Script schreiben, und dieses dann @reboot laufen lassen.
Funktioniert dies auch, weißt du ziemlich sicher, dass es am Inhalt deines ursprünglichen Scripts liegt, und nicht an den cron Mechanismen.