cron.daily wird nicht mehr automatisch ausgeführt

Hinweis: In dem Thema cron.daily wird nicht mehr automatisch ausgeführt gibt es 4 Antworten. Der letzte Beitrag () befindet sich ganz unten auf dieser Seite.
  • Hallo Community,


    ich habe mich in der Hoffnung registriert, dass ihr mir bei einem Problem helfen könnt. Vermutlich stelle ich mich nur zu dusselig an. Mein Betriebssystem ist ein SUSE Linux Enterprise Server 12 SP1. Mein Problem: Die Skripte/Programme unterhalb von /etc/cron.daily werden nicht mehr ausgeführt.



    /etc/crontab

    Code
    # cat /etc/crontab
    SHELL=/bin/sh
    PATH=/usr/bin:/usr/sbin:/sbin:/bin:/usr/lib/news/bin
    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>&1



    Das in der crontab eingetragenen Skript wird alle 15 Minuten ausgeführt, wie der folgende Auszug aus dem Systemprotokoll zeigt:


    Code
    2017-03-27T13:15:01.151520+02:00 host CRON[7638]: (root) CMD ( test -x /usr/lib/cron/run-crons && /usr/lib/cron/run-crons >/dev/null 2>&1)
    2017-03-27T13:30:01.198780+02:00 host CRON[11239]: (root) CMD ( test -x /usr/lib/cron/run-crons && /usr/lib/cron/run-crons >/dev/null 2>&1)
    2017-03-27T13:45:01.233800+02:00 host CRON[14922]: (root) CMD ( test -x /usr/lib/cron/run-crons && /usr/lib/cron/run-crons >/dev/null 2>&1)
    2017-03-27T14:00:01.271863+02:00 host CRON[18512]: (root) CMD ( test -x /usr/lib/cron/run-crons && /usr/lib/cron/run-crons >/dev/null 2>&1)
    2017-03-27T14:15:01.309890+02:00 host CRON[22072]: (root) CMD ( test -x /usr/lib/cron/run-crons && /usr/lib/cron/run-crons >/dev/null 2>&1)


    Das Skript /usr/lib/cron/run-crons führt die unter /etc/cron.{hourly,daily,weekly,monthly} abgelegten Skripte/Programme aus. Dabei prüft es anhand der Einträge in /var/spool/cron/lastrun/ wann die entsprechenden Skripte/Programme in /etc/cron.{hourly,daily,weekly,monthly} das letzte Mal ausgeführt wurden. Die letzte Ausführungszeit von cron.daily auf meinem System war vorgestern am 25.03.2017:


    Code
    # ll /var/spool/cron/lastrun/
    total 0
    -rw-r--r-- 1 root root 0 Mar 25 00:15 cron.daily
    -rw-r--r-- 1 root root 0 Mar 27 14:15 cron.hourly
    -rw-r--r-- 1 root root 0 Jul  5  2016 cron.monthly
    -rw-r--r-- 1 root root 0 Jul 22  2016 cron.weekly

    Um die Laufzeit zu überprüfen, habe ich ein Skript in /etc/cron.daily/ angelegt, welches einfach jeden Tag eine Datei unter /var/log/ anlegt. Die nächste Laufzeit hätte am 26.03.2017 um 00:15 sein müssen. Diese ist aber nicht erfolgt. Jedoch wurde ein Zeitstempel der Datei verändert, wie die folgende Ausgabe zeigt:


    Code
    # stat /var/spool/cron/lastrun/cron.daily
      File: '/var/spool/cron/lastrun/cron.daily'
      Size: 0               Blocks: 0          IO Block: 4096   regular empty file
    Device: 801h/2049d      Inode: 267202      Links: 1
    Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
    Access: 2017-03-25 00:15:01.000000000 +0100
    Modify: 2017-03-25 00:15:01.000000000 +0100
    Change: 2017-03-27 01:12:17.709295622 +0200
     Birth: -


    Wie zu erkennen ist, weicht die Change-Time hier von der Access- und Modify-Time ab. Da das Skript /usr/lib/cron/run-crons jedoch auf die Change-Time prüft, wird cron.daily nicht ausgeführt, da die letzte Laufzeit ja offensichtlich noch keine 24 Stunden zurück liegt.


    Ich hoffe, es ist mir gelungen mein Problem nachvollziehbar zu schildern. Falls nicht, fragt bitte nach.


    Meine Frage ist nun, wie kann ich herausfinden, welcher Prozess die Datei nachts verändert? Was kann dazu führen, dass Change- und Modify-Time divergieren?


    Wenn ich die Datei /var/spool/cron/lastrun/cron.daily lösche, wird beim nächsten Lauf von /usr/lib/cron/run-crons sowohl die Datei neu angelegt, als auch die Skripte/Programme unterhalb von /etc/cron.daily/ ausgeführt. In diesem Moment stimmen auch alle drei Zeitstempel überein. Danach laufen sie jedoch wieder auseinander und die Skripte unter /etc/cron.daily/ werden erneut nicht mehr ausgeführt.



    Ich freue mich über eure Unterstützung.



    Viele Grüße
    Tronde

    Für den Inhalt des Beitrages 106622 haftet ausdrücklich der jeweilige Autor: Tronde

  • Hi,


    ich habe aktuell den installierten Virenscanner in Verdacht. Für diesen ist in der Crontab des users root ein On-Demand-Scan eingestellt. Ich vermute, dass der Scan beim Zugriff auf die Datei nur die ctime ändert bzw. atime und ctime ändert, den Zugriff auf die atime anschließend aber zurücksetzt.


    Ich habe das Verzeichnis /var/spool/cron/lastrun vom Scan augeklammert und werde hier morgen berichten, ob sich der Verdacht erhärten ließ.

    Für den Inhalt des Beitrages 106624 haftet ausdrücklich der jeweilige Autor: Tronde

  • Da würde ich erst mal das journalctl durchforsten.


    Außerdem ist die Suche nach ctime sinnlos. cron verwendet mtime oder die inotify Infrastruktur des Kernels.
    (Die so häufig mistverstandene®™ ctime ist eben NICHT die letzte Änderung eines Files. Sie bezieht sich auf eine Änderung der Rechte.)


    Und was steht denn in den entsprechendem systemd service file?
    Der Dienst arbeitet sonst aber schon einwandfrei?


    Es lohnt auch ein Blick in die Datei /etc/anacrontab, falls vorhanden.

  • Guten Morgen,


    es kann mit hinreichender Sicherheit davon ausgegangen werden, dass der Virenscanner die Ursache war. Nachdem das Verzeichnis /var/spool/cron/lastrun vom Scan ausgeschlossen wurde, wird cron.daily wieder korrekt ausgeführt. Ich gehe davon aus, dass auch cron.monthly wieder korrekt laufen wird, wenn seine Zeit gekommen ist.


    Die ctime ist in diesem Fall nicht unerheblich, denn das Skript /usr/lib/cron/run-crons prüft anhand der ctime, ob die Skripte unter /etc/cron.{hourly,daily,monthly,weekly} ausgeführt werden sollen oder nicht. Da die ctime täglich durch den Virenscanner verändert wurde, hat das genannte Skript die Jobs nicht mehr ausgeführt.


    In der Dokumentation des Virensanncers habe ich auch nochmal eine Bestätigung gefunden, dass dieser standardmäßig die atime auf den ursprünglichen Wert zurücksetzt und lediglich die ctime ändert.


    Das Thema ist damit für mich gelöst.


    MfG
    Tronde

    Für den Inhalt des Beitrages 106649 haftet ausdrücklich der jeweilige Autor: Tronde

  • Mea culpa.
    Das /var/spool hab ich nicht bedacht.
    Dort ist wirkt der Test auf ctime ja, wie eine Art Lockfile, halt für die Zeit. Atime und mtime würden dort keinen Sinn machen, bzw. wären sogar kontraproduktiv, da die ja getouched werden könnten.


    Was mich aber wundert, ist, dass der Virenscanner da drin rumfuhrwerkt.


    /var/spool würde ich vom Scan komplett ausnehmen, oder bei wirklich guten Gründen selektiv mitscannen lassen.