Cronjobs hauen nicht hin

[tobo]

Ne, eigentlich ist das auch nicht so schwer.
Wie heißt denn jetzt dein normaler Benutzername und wo liegt sein Benutzerverzeichnis? Zeige mal die Root-Ausgaben von

Code: Alles auswählen

grep -i cron /var/log/syslog | tail -20
service cron status

oder seiner systemd-Entsprechungen.

PS: Das Skript funktioniert nicht mehr wegen dem exit. Ansonsten würde das ja jedesmal durchlaufen. Wenn das Skript manuell läuft, dann existiert danach die Datei FILE?

[casu4711]

ok habs jetzt rausgefunden wo das Geheimnis liegt, die Scripte müssen im

/usr/local/bin/scripts liegen sonst geht es nicht.


vielen Dank noch mal für die Anregungen und ein schönes Wocheende

lg

[tobo]

1. Stimmt das so global nicht und 2. wieso Skript(e) und 3. liegt das Skript doch auch dort?! Gute Nacht...

[casu4711]

ich habe es nie nach usr geschrieben, nur nach /home, das hat mich ja auch verwundert, in der cronliste wird ja auch auf /home verwiesen aber er füht das script nur aus usr aus

[thoerb]

ich habe es nie nach usr geschrieben, nur nach /home, das hat mich ja auch verwundert, in der cronliste wird ja auch auf /home verwiesen aber er füht das script nur aus usr aus

In der Crontab steht seit deinem ersten Beitrag:

Code: Alles auswählen

54 17 * * * /bin/sh /usr/local/bin/scripts/backup_script.sh

[casu4711]

ja das hatte ich zwischendurch zum Testen aber zum Schluss standen die auf home, sorry

[dasebastian]

Ich kann komplett falsch liegen, habe aber von irgendwoher (TM) in Erinnerung, dass für Cronjobs die Skripte keine .sh Extension haben sollen.

Wenn ich falsch liege, bitte einfach sagen: du liegst falsch.

[MSfree]

Ich kann komplett falsch liegen, habe aber von irgendwoher (TM) in Erinnerung, dass für Cronjobs die Skripte keine .sh Extension haben sollen.

Wenn ich falsch liege, bitte einfach sagen: du liegst falsch.

Du liegst falsch.

Unter unixoiden Betriebssystemen ist der Punkt nur Bestandteile des Dateinamens, Endungen wie unter CP/M, DOS oder Windows gibt es hier nicht. ".sh" im Dateinamen bewirkt also rein gar nichts, ausser den Dateinamen zu verlängerm. Der Aufruf eines Skriptes bzw. Programms muß ja auch immer den vollen Dateinamen enthalten.

Unter Windows kann man das Programm notepad.exe aufrufen, indem man nur notepad in die Kommandozeile eingibt. Unter Linux muß man immer den vollständigen Namen angeben.

[whisper]

Ich kann komplett falsch liegen, habe aber von irgendwoher (TM) in Erinnerung, dass für Cronjobs die Skripte keine .sh Extension haben sollen.

Wenn ich falsch liege, bitte einfach sagen: du liegst falsch.

Ich glaube, das sind die Scripte in cron.daily etc.
Da ist die extension nicht erlaubt.

[dasebastian]

Du liegst falsch. ...

Danke für die Richtigstellung!

Ich glaube, das sind die Scripte in cron.daily etc.
Da ist die extension nicht erlaubt.

Das kann sein, ich habe das in einem YT-Video aufgeschnappt und da ich selber auch ein Skript in cron.daily liegen habe, habe ich dem auch keine Extension gegeben.

[casu4711]

ok dass ist ja interessant, ich dachte in Linux sei die Endung prinzipielle eher irrelevant

lg

[TRex]

Das hat aber nen komplett anderen Grund - wenn du in /etc/ Konfigurationsdateien liegen hast, die von der Distribution geschrieben und aktualisiert werden, dann liegt da auch mal beispielsweise 10-auth.conf.dpkg-dist rum - kann bei Konfigurationsänderungen passieren - und dann willst du nicht, dass die gelesen wird. Manche Programme sind dann schlau bzw. restriktiv genug, nur *.conf zu lesen oder sowas in der Art. Meine /etc/apt/sources.list.d/ Dateien enden auf .list, und ich weiß ehrlich gesagt nicht mehr, ob das nur meine Konvention ist.

[JTH]

Meine /etc/apt/sources.list.d/ Dateien enden auf .list, und ich weiß ehrlich gesagt nicht mehr, ob das nur meine Konvention ist.

Da ist es tatsächlich vorgeschrieben. Es gibt sogar zwei verschiedene Endungen, für die beiden möglichen sources.xxx-Dateiformate:

The /etc/apt/sources.list.d directory provides a way to add sources.list entries in separate files. Two different file formats are allowed as described in the next two sections. Filenames need to have either the extension .list or .sources depending on the contained format.

Das ermöglicht es zu.B. auch, eine Datei README in dem betreffenden Ordner abzulegen, die aber nur Hilfe bietet, aber von der Anwendung selbst ignoriert wird. Manche anderen Anwendungen machen genau so etwas – aber eben nicht, weil die Dateiendung technisch notwendig wäre.

[florit]

Code: Alles auswählen

*/54 */8 * * * /bin/bash /path/to/backup.sh

Jede 8 stunden und 54 Minuten

[homer65]

Anstatt Dich mit CRON rumzuquälen und gar keine Fehlermeldungen zu bekommen, könntest du mit Systemd Unit arbeiten.
Dazu speicherst du Folgendes in /etc/systemd/system/backup.service ab

Code: Alles auswählen

[Unit]
Description=Mein Backup
[Service]
Type=simple
ExecStart=/usr/local/bin/scripts/backup.sh
WorkingDirectory=//usr/local/bin/scripts

Desweiteren in /etc/systemd/system/backup.timer

Code: Alles auswählen

[Unit]
Description Mein Backup Timer
[Timer]
OnCalendar=Mon-Sun *-*-* 18:00:00
Unit=backup.service
[Install]
WantedBy=multi-user.target

Dann setzt Du noch zwei Befehle ab, um den Timer scharf zu machen

Code: Alles auswählen

systemctl enable backup.timer
systemctl start backup.timer

Fertig. Dein Skript wird jeden Tag um 18Uhr gestartet.
Meldungen und Fehlermeldungen siehst Du mit journalctl.

[tobo]

Anstatt Dich mit CRON rumzuquälen ...

Im Unterschied zu dem Aufwand, den du hier treibst, ist das in Cron eine Zeile.

... und gar keine Fehlermeldungen zu bekommen,

Das Mail-System ist dir unbekannt?

[kemir]

Das geht ja hier drunter und drüber.
Um welchen Benutzer geht es überhaupt? Nennen wir ihn 'bob', dann kann bob in sein HOME-Verzeichnis /home/bob schreiben.
Nach /home selbst kann/darf nur der Account 'root' schreiben, und legt dort üblicherweise die Homeverzeichnisse der Systembenutzer an, also z.B. /home/bob.
Nach /home/scripts sollte nur der Benutzer 'scripts' schreiben dürfen, falls es den gibt.
'root' darf natürlich überall schreiben, aber das ist ja hier nicht gewollt.

Weiterhin, weil der Fragesteller da einiges durcheinander wirft: das HOME-Verzeichnis von Benutzer 'root' ist /root , und das ist nicht das "root-Verzeichnis" ("/") !
Das eine ist das root-Verzeichnis des Systems, das andere sind die Home-Verzeichnisse der diversen Accounts, das Home_Verzeichnis des speziellen Accounts 'root' ist /root.
Das hat damit zu tun, dass 'root' sich auch dann einloggen können soll, wenn/falls das Darteisystem /home bei Systemstart noch nicht gemountet ist.
Apropos: /home sollte immer ein eigenes/separates Dateisystem sein, sonst legen unachtsame Anwender das System gerne (unbeabsichtigt) lahm.

Durch einen Dummy-Eintrag im Minutenrhythmus erst mal feststellen, ob cron an sich funktioniert und wohin das Script schreibt. Es gibt Systeme, da müssen User-Crontabs explizit erlaubt werden ...

Anstatt /home/irgendwas wäre sinnvoller, gleich das universelle ${HOME} zu nehmen, dann kann das Script von jedem für seine Dateien eingesetzt weden; und man findet nebenbei heraus, als welcher Benutzer der cron-Job ausgeführt wird.

Noch ein Wort zu den cron-Dateien: eine abschließende Zeile nur mit einem "#" (und ggf. mit beliebig vielen Leerzeichen) ist nicht erforderlich, allerdings reagiert cron oft unwirsch auf Leerzeilen, egal wo (das war früher zumindest so).

##