Crontab zeigt keine Wirkung
Hallo zusammen.
Ich bin gerade von Windows auf Linux umgestiegen und möchte jetzt ein Script zeitgesteuert über crontab laufen lassen.
Das erweist sich als schwieriger, als es auf den ersten Blick aussieht.
Was bisher geschah:
Zuerst habe ich ein kleines Script geschrieben, das einfache Zeilenmanipulationen an einer Textdatei vornimmt.
Dieses gehöhrt root und liegt im Ordner /usr/bin und ist ausführbar und funktioniert soweit.
Dann habe ich eine Kopie erzeugt mit
und diese dann editiert mit
Sodas ein
folgendes Ergebnis liefert:
Wobei die letzten zwei Zeilen von mir eingefügt wirden in dem Versuch, das Script zeitgesteuert laufen zu lassen mit der Variation der unterschiedlichen Pfadangaben, falls das etwas mit dem nichtfunktionieren zu tuen hatt.
Hier zum testen minütlich.
Leider musste ich feststellen, das zwar der händische Aufruf funktioniert, der zeitgesteuerte über crontab hingegen nicht.
Das System ist SuseLinux und auch in den Ordner /etc/cron-hourly habe ich das Script test.sh abgelegt, aber ohne Wirkung.
Das Script selber hat folgenden Inhalt:
Jetzt weiß ich in dieser Hinsicht nicht weiter und freue mich über helfendes mitdenken.
Das soll jetzt also der erste crontab-Lauf werden und irgendwas funktioniert nicht.
Gruß
Fraenky
Ich bin gerade von Windows auf Linux umgestiegen und möchte jetzt ein Script zeitgesteuert über crontab laufen lassen.
Das erweist sich als schwieriger, als es auf den ersten Blick aussieht.
Was bisher geschah:
Zuerst habe ich ein kleines Script geschrieben, das einfache Zeilenmanipulationen an einer Textdatei vornimmt.
Dieses gehöhrt root und liegt im Ordner /usr/bin und ist ausführbar und funktioniert soweit.
Dann habe ich eine Kopie erzeugt mit
crontab /etc/crontab
crontab -e
crontab -l
SHELL=/bin/sh
PATH=/usr/bin:/usr/sbin:/sbin:/bin:/usr/lib/news/bin:/home/user/test
MAILTO=root
#
# check scripts in cron.hourly, cron.daily, cron.weekly, and cron.monthly
#
-*/15 * * * * root test -x /usr/lib/cron/run-crons && /usr/lib/cron/run-crons >/dev/null 2>&1h
#
1 * * * * root /home/user/test/test.sh
1 * * * * root test.sh
Hier zum testen minütlich.
Leider musste ich feststellen, das zwar der händische Aufruf funktioniert, der zeitgesteuerte über crontab hingegen nicht.
Das System ist SuseLinux und auch in den Ordner /etc/cron-hourly habe ich das Script test.sh abgelegt, aber ohne Wirkung.
Das Script selber hat folgenden Inhalt:
#!/bin/bash
DATEI=/pfad/test
tail -1 $DATEI >$DATEI.tmp
cat $DATEI >>$DATEI.tmp
head --lines=-1 $DATEI.tmp > $DATEI
rm /pfad/*.tmp*
Jetzt weiß ich in dieser Hinsicht nicht weiter und freue mich über helfendes mitdenken.
Das soll jetzt also der erste crontab-Lauf werden und irgendwas funktioniert nicht.
Gruß
Fraenky
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 139968
Url: https://administrator.de/forum/crontab-zeigt-keine-wirkung-139968.html
Ausgedruckt am: 22.12.2024 um 21:12 Uhr
8 Kommentare
Neuester Kommentar
Hallo,
wenn ich mich nicht irre, dann sollten Zeile 1-8 in deiner privaten Crontab nix zu suchen haben. Dies ist die globale Crontab (welche du ja von /etc/crontab kopiert hast), die dann immer wieder prüft, ob es nicht lokale gibt und wenn es lokale gibt, dann wird wieder überprüft, ob......
Also einfach mal alles ausser Zeile 9+10 raus aus der user-crontab.
<edit>
achso, das root solltest du auch entfernen, weil die liste ja eh root gehört. Also nur noch
1 * * * * /home/user/test/test.sh
1 * * * * test.sh
</edit>
Lg
Matze
wenn ich mich nicht irre, dann sollten Zeile 1-8 in deiner privaten Crontab nix zu suchen haben. Dies ist die globale Crontab (welche du ja von /etc/crontab kopiert hast), die dann immer wieder prüft, ob es nicht lokale gibt und wenn es lokale gibt, dann wird wieder überprüft, ob......
Also einfach mal alles ausser Zeile 9+10 raus aus der user-crontab.
<edit>
achso, das root solltest du auch entfernen, weil die liste ja eh root gehört. Also nur noch
1 * * * * /home/user/test/test.sh
1 * * * * test.sh
</edit>
Lg
Matze
Zitat von @Fraenky:
Oder, falls das irgendwas mit dem Script zu tun hat, was könnte ich denn mal per Crontab starten, was sicher funktionieren
müsste, um erst mal die Ansprechbarkeit von crontab zu überprüfen?
Oder, falls das irgendwas mit dem Script zu tun hat, was könnte ich denn mal per Crontab starten, was sicher funktionieren
müsste, um erst mal die Ansprechbarkeit von crontab zu überprüfen?
echo "rennt" > /home/user/crontest.txt
das schreibt "rennt" ohne "" in eine Textdatei. Den Ordnerpfad musst du natürlich anpassen.
<edit>
Du weißt aber schon, dass 1 * * * * immer zur ersten Minute einer Stunde ausgeführt wird?
Also 20:01, 21:01, 22:01 und nicht jede Minute?!
Du könntest also */1 nehmen, dann wäre es jede Minute.
</edit>
Lg
Matze
N'Abend,
was mir nicht so ganz einleuchtet: Warum kopierst du die crontab ??
Ich kenne es nur so das man als betreffender User einfach crontab -e ausführt und gut ...
Wenn man keine hat, nimmt crontab eine leere ...
VG
Deepsys
PS: Ich würde nie ein Linux-Script test.sh nennen, es gibt ein bashprogramm namens test (allerdings ohne .sh)und wenn du da beim Aufruf durcheinander kommst ....
was mir nicht so ganz einleuchtet: Warum kopierst du die crontab ??
Ich kenne es nur so das man als betreffender User einfach crontab -e ausführt und gut ...
Wenn man keine hat, nimmt crontab eine leere ...
VG
Deepsys
PS: Ich würde nie ein Linux-Script test.sh nennen, es gibt ein bashprogramm namens test (allerdings ohne .sh)und wenn du da beim Aufruf durcheinander kommst ....
Zitat von @Deepsys:
N'Abend,
was mir nicht so ganz einleuchtet: Warum kopierst du die crontab ??
Ich kenne es nur so das man als betreffender User einfach crontab -e ausführt und gut ...
Wenn man keine hat, nimmt crontab eine leere ...
N'Abend,
was mir nicht so ganz einleuchtet: Warum kopierst du die crontab ??
Ich kenne es nur so das man als betreffender User einfach crontab -e ausführt und gut ...
Wenn man keine hat, nimmt crontab eine leere ...
Weil dann Umgebungsvariablen schon gesetzt werden können, so wie der Systemadmin es vorgesehen haben könnte? Und solange die Benutzer es dann nicht löschen..
VG
Deepsys
PS: Ich würde nie ein Linux-Script test.sh nennen, es gibt ein bashprogramm namens test (allerdings ohne .sh)und wenn du da
beim Aufruf durcheinander kommst ....
Deepsys
PS: Ich würde nie ein Linux-Script test.sh nennen, es gibt ein bashprogramm namens test (allerdings ohne .sh)und wenn du da
beim Aufruf durcheinander kommst ....
ich nenne sie immer rm-rf-/.sh da ist bisher noch nie was passiert
Lg
Matze
> Zitat von @Deepsys:
Weil dann Umgebungsvariablen schon gesetzt werden können, so wie der Systemadmin es vorgesehen haben könnte? Und solange
die Benutzer es dann nicht löschen..
Weil dann Umgebungsvariablen schon gesetzt werden können, so wie der Systemadmin es vorgesehen haben könnte? Und solange
die Benutzer es dann nicht löschen..
OK, das macht Sinn.
ich nenne sie immer rm-rf-/.sh da ist bisher noch nie was passiert
Gute Idee, das mache ich nun auch immer
VG
Deepsys