• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

[Gelöst] Cron logs/jobs anzeigen

wbwb

Hacker
Hallo,

ich versuche unter Leap 42.3 meine cron logs zu lesen - eigentlich nur um zu sehen ob/wann fstrim auf meiner supertollennagelneueglänzenden SSD ausgeführt wird. Ich bekomme aber (fast) keinen output.

1) wenn ich mich überhaupt erst mal informieren möchte was im Prinzip laufen sollte, dann dachte ich, dass ich
Code:
crontab -l
ausführe? Da bekomme ich aber nur
Code:
no crontab for xxxxx
sowohl für root als auch für normale Nutzer. Ich habe aber in /etc sehr wohl eine Reihe Directories
Code:
./cron.monthly, ./cron.weekly, ./cron.d, ./cron.hourly, ./cron.daily
und z.B. in cron.daily befinden sich eine Reihe Skripten, von denen ich glaube(hoffe), dass sie ausgeführt werden, z.B. mlocate.cron für updatedb.
Sollte die crontab so etwas nicht anzeigen?
Was verstehe ich da falsch?

2) wenn ich sehen will was cron wirklich tut, dachte ich, sollte man als root
Code:
journalctl _COMM=cron
ausführen? Da bekomme ich nur massenhaft dass Pärchen
Code:
ABC xxxxy linux-fask.suse cron[fghij]: pam_unix(crond:session): session opened for user root by (uid=0)
ABC xxxxx linux-fask.suse CRON[abcde]: pam_unix(crond:session): session closed for user root
was nicht gerade nach sehr 'viel' aussieht? (Dasselbe gilt auch für den Output von journalctl | grep cron | less)
Kann man da nicht noch ein paar mehr infos bekommen?
Oder heißt das, dass cron auf meinem System einfach nix macht?

wbwb
 

marce

Guru
die cron.daily, ...-Verzeichnisse werden (üblicherweise) von anachron verwendet. Für Desktop-Systeme, die nicht 24x7 laufen ist das meist auch die wesentlich bessere und zuverlässerigere Methode.

Keine ded. Crontab für einzelne User (auch root) zu haben ist per se eigentlich nicht verwunderlich. Ded. Cron-Jobs des Systems findet man heute eher in /etc/cron.d/* anstatt in der Crontab (allein aus verwaltungstechnischen Gründen auch sinnvoll) - wenn nicht wie oben erwähnt bereits durch anachron "erledigt".

Wo der Job bei Dir hinlogt müsste man in der entsprechenden Konfiguration finden - sei's daß der Logger über systemd definiert wird, ein entsprechendes syslog-Konfig-File existiert oder direkt in einer evtl. anachron-Konfig.
 
OP
W

wbwb

Hacker
marce schrieb:
...anachron verwendet. Für Desktop-Systeme, die nicht 24x7 laufen...
ok. - aber müsste das nicht heißen, dass ich auf dem System irgendwelche Spuren von anacron, z.B. eine /etc/anacrontab und einen anacron Dämon vorfinden. Weder habe ich aber das erstere, noch finde ich das zweite. Ein cron Dämon läuft übrigens. Wenn ich außerdem OpenSuSEs Software-Liste ansehe, dann finde ich nur das RPM cronie-anacron, dass bei mir aber nicht nicht installiert ist und von dem es bei OpenSuSE heißt: "Anacron became part of cronie...blablabla..."

Würdest Du damit dann schließen, dass auf meinem Gerät kein korrektes cron-job Management stattfindet?
.
marce schrieb:
Wo der Job bei Dir hinlogt müsste man in der entsprechenden Konfiguration finden - sei's daß der Logger über systemd definiert wird, ein entsprechendes syslog-Konfig-File existiert...
hmm? Hilf mir doch bitte noch ein bisschen mehr auf die Sprünge wo ich da nachsehen muss.

wbwb
 

Sauerland

Ultimate Guru
Geht alles mit systemd:
Code:
systemctl status fstrim.timer 
● fstrim.timer - Discard unused blocks once a week
   Loaded: loaded (/usr/lib/systemd/system/fstrim.timer; enabled; vendor preset: enabled)
   Active: active (waiting) since Mi 2017-10-04 21:24:44 CEST; 2 days ago
     Docs: man:fstrim

Okt 04 21:24:44 linux64 systemd[1]: Started Discard unused blocks once a week.

Code:
journalctl -a | grep -i fstrim
 
OP
W

wbwb

Hacker
:eek:ps: wow ... systemd/timers ... noch ein parallel laufendes Timersystem ... ich werde linux wohl nie aber auch nur zu 10% kennen :(
Ok. da habe ich also nun 'nur' 3 timer auf dem System laufen
Code:
~>systemctl list-timers --all
NEXT                         LEFT          LAST                         PASSED       UNIT                         ACTIVATES
So 2017-10-08 00:00:00 CEST  2h 37min left Sa 2017-10-07 00:00:01 CEST  21h ago      logrotate.timer              logrotate.service
So 2017-10-08 19:58:42 CEST  22h left      Sa 2017-10-07 19:58:41 CEST  1h 23min ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service
Mo 2017-10-09 00:00:00 CEST  1 day 2h left Mo 2017-10-02 07:56:58 CEST  5 days ago   fstrim.timer                 fstrim.service
und der fstrim Prozess ist dabei. Gut.

Was aber sind dann diese
Code:
ABC xxxxy linux-fask.suse cron[fghij]: pam_unix(crond:session): session opened for user root by (uid=0)
ABC xxxxx linux-fask.suse CRON[abcde]: pam_unix(crond:session): session closed for user root
logs, die mir journalctl _COMM=cron ausgiebt, wenn ich (a) weder eine crontab noch eine anacrontab habe und (b) systemctl status cron mir sagt, dass der cron.service active (running) ist?
Bedeutet das, dass der cron.service einfach im 'Leerlauf' ist?

Außerdem, was führt denn dann das updatedb für locate aus, von dem ich bisher ausging, dass es durch /etc/cron.daily/mlocate.cron von cron durchgeführt wird?

wbwb
 

Sauerland

Ultimate Guru
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 ergibt bei mir alle 15 Minuten einen Eintrag in dem log mit:
Okt 08 07:30:01 linux64 cron[24452]: pam_unix(crond:session): session opened for user root by (uid=0)
Okt 08 07:30:01 linux64 CRON[24452]: pam_unix(crond:session): session closed for user root
Okt 08 07:45:01 linux64 cron[24862]: pam_unix(crond:session): session opened for user root by (uid=0)
Okt 08 07:45:01 linux64 CRON[24862]: pam_unix(crond:session): session closed for user root
Okt 08 08:00:01 linux64 cron[25276]: pam_unix(crond:session): session opened for user root by (uid=0)
Okt 08 08:00:02 linux64 CRON[25276]: pam_unix(crond:session): session closed for user root
Okt 08 08:15:01 linux64 cron[25688]: pam_unix(crond:session): session opened for user root by (uid=0)
Okt 08 08:15:01 linux64 CRON[25688]: pam_unix(crond:session): session closed for user root
 
OP
W

wbwb

Hacker
Ok., bin ich also schon wieder reingefallen. Natürlich habe ich auch eine solche
Code:
/etc/crontab
bei mir (habe ja auch eine 42.3 laufen). Aber wozu ist dann der Befehl
Code:
crontab -l
überhaupt gut, wenn er diese Datei /etc/crontab gar nicht anzeigt, bzw ausgibt
no crontab for root
Damit hatte ich halt angenommen, dass ich keine crontab hätte.
.
.
Außerdem noch dies: wenn ich mehr log output von den einzelnen cronjobs haben möchte, müsste ich dann die cron.daily usw. Skripten editieren? Oder gibt es da noch etwas Besseres?

wbwb
 

marce

Guru
/etc/crontab ist die Systemcrontab. crontab -l zeigt die User-Crontab. Die liegt unter /var/spool/cron/$username.

Unnötige Ausgaben von Cronjobs will man eigentlich keine haben - die bekommt man entweder nämlich als nervige Mails oder sie müllen das Logfile zu.

Fehler sollten so oder so geloggt werden - entweder im Logfile des Cron-Daemons oder auch per Mail an den entsprechenden Benutzer, der den Cronjob gestartet hat - auch das hängt wieder von der Konfiguration des jeweiligen Cronjobs ab.

Details siehe Doku des verwendeten Cron-Daemons, der Distribution und des Systemloggers.
 
Oben