RootForum Community

Hallo,
ein kniffliges Problem.
Server mit SuSE-Linux, Crontab eingerichtet mit Datensicherungsscript (MO-FR, 22.00)

Konstellation:
1. Crontab wird gestartet, Prozess läuft, Sicherungsscript funktioniert.
2. Zu Testzwecken wird das Systemdatum in die Vergangenheit geändert, Cron-Prozess wird nicht "angefasst", Datum ist auch beim nächsten Cron-Termin noch in der Vergangenheit, Sicherungsscript wird nicht gestartet.
## Alle möglichen Datumsumstellungskonstellationen wurden ausprobiert (wieder aktualisieren, mit "hwclock" Sys-Time und Bios-Time synchronisieren), alles vergebens.
3. Cron-Prozess wird manuell gekillt und neu gestartet bzw. System-Reboot wird durchgeführt (wo der Cron-Prozess auch neu gestartet wird),
danach wird Sicherungsscript wieder ausgeführt.

Frage:
Was bewirkt die Ã?nderung der Systemzeit beim Cron-Prozess? Wird er dadurch auf Eis gelegt und macht nichts, obwohl die Bedingungen zutreffen?

Profis an die Front.

Thanx vorab.
Nisi

Frage:
Was bewirkt die Ã?nderung der Systemzeit beim Cron-Prozess? Wird er dadurch auf Eis gelegt und macht nichts, obwohl die Bedingungen zutreffen?

Nein - so sollte das nicht laufen!

Sicher, dass das Script nicht startet ? Bleibt es vielleicht hängen weil es selbst Datumsprüfung vornimmt? Mal mit nem HelloWorld Script ausprobiert?

Zeig mal CronTab-Eintrag ...

:?: Warum änderst Du das Datum, wenn es doch läuft :?:
(Nur so am Rande)

mc5000 wrote:
Nein - so sollte das nicht laufen!

Sicher, dass das Script nicht startet ? Bleibt es vielleicht hängen weil es selbst Datumsprüfung vornimmt? Mal mit nem HelloWorld Script ausprobiert?

Zeig mal CronTab-Eintrag ...

:?: Warum änderst Du das Datum, wenn es doch läuft :?:
(Nur so am Rande)

So sieht unsere crontab (crontab -l) aus, den DUMMY-Eintrag haben wir mal eingefügt, weil es Probleme gab:
solgd9112:~ # crontab -l
# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (/tmp/crontab.12370 installed on Tue Feb 1 06:50:32 2005)
# (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)
#
# Dummy-Auftrag:
# am 3.12. um 1.00 h
#
0 1 3 12 * echo "Test Cron-Job" > /tmp/crontest
#
# Sicherung Verzeichnisse und Dateien gem. Eintrag im Script
# taeglich mo-fr um 22.00 h
#
00 22 * * 1-5 /usr1/kommandos/cron-si01
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
solgd9112:~ #


Die Ã?nderung des Datum ist für Testzwecke erforderlich und muss sein.
Wir sind eine Verfahrenspflegestelle der Justiz NRW und entwickeln und pflegen Software für die Gerichtskassen. Das Problem taucht in userer eigenen Entwicklungs- und Testumgebung auf.

Danke schon mal für Dein Interesse.

Nisi

bis auf das 00 hätte ich das auch geschrieben - doch das sollte egal sein.

Naja, cron hat manchmal Schwierigkeiten beim Wechsel zur Sommerzeit. Das trifft hier wohl nicht zu. Auf welches Datum/Uhrzeit stellt Du das System denn um??

Wird was ins Log geschrieben? Mal versucht die Kiste mit mehr debuginfos laufen zu lassen?

Available options:
-j jitter
-J rootjitter
-s
-o
-x debugflag[,...]

bit currently not used
ext make the other debug flags more verbose
load be verbose when loading crontab files
misc be verbose about miscellaneous one-off events
pars be verbose about parsing individual crontab lines
proc be verbose about the state of the process
sch be verbose when iterating through the scheduling algorithms
test trace through the execution, but do not perform any actions

mc5000 wrote:bis auf das 00 hätte ich das auch geschrieben - doch das sollte egal sein.

Naja, cron hat manchmal Schwierigkeiten beim Wechsel zur Sommerzeit. Das trifft hier wohl nicht zu. Auf welches Datum/Uhrzeit stellt Du das System denn um??

Wird was ins Log geschrieben? Mal versucht die Kiste mit mehr debuginfos laufen zu lassen?

In welcher LOG-Datei müsste ich denn zu 07.03.2005 - 22.00 etwas finden? Und wo könnte ich DEBUG-Einstellungen ändern?

Das Datum haben wir auf Ende Januar oder Anfang Februar umgestellt, aber immer ein Datum gewählt, dass die Cron-Bedingung Mo-Fr erfüllt gewesen ist.

Nisi

also ich lasse mir die Ausgabe der (root)Cronjobs auf das Root-Postfach ausgeben (ist glaub ich auch standard ...)
sonst das systemlog :idea:

Debugeinstellungen im start des cron-daimon ergänzen - cron neu starten und schauen.

mc5000 wrote:also ich lasse mir die Ausgabe der (root)Cronjobs auf das Root-Postfach ausgeben (ist glaub ich auch standard ...)
sonst das systemlog :idea:

Debugeinstellungen im start des cron-daimon ergänzen - cron neu starten und schauen.

So sieht unsere System-Log-Datei normalerweise aus, siehe auch die diversen Cron-Einträge. Um 22.00 startet unser Script:

Mar 4 20:59:00 solgd9112 /USR/SBIN/CRON[3352]: (root) CMD ( rm -f /var/spool/cron/lastrun/cron.hourly)
Mar 4 21:22:12 solgd9112 -- MARK --
Mar 4 21:42:12 solgd9112 -- MARK --
Mar 4 21:59:00 solgd9112 /USR/SBIN/CRON[3472]: (root) CMD ( rm -f /var/spool/cron/lastrun/cron.hourly)
Mar 4 22:00:00 solgd9112 /USR/SBIN/CRON[3476]: (root) CMD (/usr1/kommandos/cron-si01)
Mar 4 22:00:00 solgd9112 kernel: sym53c1010-66-0-<5,*>: FAST-10 WIDE SCSI 20.0 MB/s (100.0 ns, offset 15)
Mar 4 22:00:02 solgd9112 su: (to oracle) root on none
Mar 4 22:00:02 solgd9112 PAM-unix2[3526]: session started for user oracle, service su
Mar 4 22:00:07 solgd9112 PAM-unix2[3526]: session finished for user oracle, service su
Mar 4 22:00:07 solgd9112 su: (to oracle) root on none


So sieht die Log-Datei aus, wenn das Datum geändert wurde:

Jan 31 11:07:25 solgd9112 in.telnetd[11893]: connect from Nieswandj@10.16.20.10 (10.16.20.10)
Jan 31 11:07:30 solgd9112 login: FAILED LOGIN 1 FROM 10.16.20.10 FOR root, Authentication failure
Jan 31 11:08:06 solgd9112 crontab[11917]: (root) LIST (root)
Jan 31 11:08:33 solgd9112 PAM-unix2[11890]: session finished for user root, service su
Jan 31 11:21:15 solgd9112 -- MARK --
Jan 31 11:41:15 solgd9112 -- MARK --
Jan 31 12:01:15 solgd9112 -- MARK --
Jan 31 12:21:15 solgd9112 -- MARK --
Jan 31 12:41:15 solgd9112 -- MARK --
Jan 31 13:01:15 solgd9112 -- MARK --
Jan 31 13:21:15 solgd9112 -- MARK --
Jan 31 13:41:15 solgd9112 -- MARK --
Jan 31 14:01:15 solgd9112 -- MARK --
Jan 31 14:21:15 solgd9112 -- MARK --
Jan 31 14:41:15 solgd9112 -- MARK --
Jan 31 14:56:07 solgd9112 in.telnetd[12167]: connect from kopatze@10.16.21.151 (10.16.21.151)
Jan 31 15:21:15 solgd9112 -- MARK --
Jan 31 15:35:15 solgd9112 in.ftpd[12235]: connect from Nieswandj@10.16.20.10 (10.16.20.10)
Jan 31 15:38:23 solgd9112 in.telnetd[12266]: connect from Nieswandj@10.16.20.10 (10.16.20.10)
Jan 31 15:41:30 solgd9112 in.ftpd[12296]: connect from Nieswandj@10.16.20.10 (10.16.20.10)
Jan 31 16:01:15 solgd9112 -- MARK --
Jan 31 16:21:15 solgd9112 -- MARK --
Jan 31 16:41:15 solgd9112 -- MARK --
Jan 31 17:01:15 solgd9112 -- MARK --
Jan 31 17:21:15 solgd9112 -- MARK --
Jan 31 17:41:15 solgd9112 -- MARK --
Jan 31 18:01:15 solgd9112 -- MARK --
Jan 31 18:21:15 solgd9112 -- MARK --
Jan 31 18:33:40 solgd9112 in.ftpd[12303]: connect from 10.195.129.99 (10.195.129.99)
Jan 31 19:01:15 solgd9112 -- MARK --
Jan 31 19:21:15 solgd9112 -- MARK --
Jan 31 19:41:15 solgd9112 -- MARK --
Jan 31 20:01:15 solgd9112 -- MARK --
Jan 31 20:21:15 solgd9112 -- MARK --
Jan 31 20:41:15 solgd9112 -- MARK --
Jan 31 21:01:15 solgd9112 -- MARK --
Jan 31 21:21:15 solgd9112 -- MARK --
Jan 31 21:41:15 solgd9112 -- MARK --
Jan 31 22:01:15 solgd9112 -- MARK --
Jan 31 22:21:15 solgd9112 -- MARK --
Jan 31 22:41:15 solgd9112 -- MARK --
Jan 31 23:01:15 solgd9112 -- MARK --
Jan 31 23:21:15 solgd9112 -- MARK --
Jan 31 23:41:15 solgd9112 -- MARK --
Feb 1 00:01:15 solgd9112 -- MARK --
Feb 1 00:21:15 solgd9112 -- MARK --
Feb 1 00:41:15 solgd9112 -- MARK --
Feb 1 01:01:15 solgd9112 -- MARK --
Feb 1 01:21:15 solgd9112 -- MARK --
Feb 1 01:41:15 solgd9112 -- MARK --

Keine Cron-Aktivitäten mehr zu erkennen.

Feb 1 06:49:41 solgd9112 su: (to root) ede on /dev/pts/0
Feb 1 06:49:41 solgd9112 PAM-unix2[12365]: session started for user root, service su
Feb 1 06:50:24 solgd9112 crontab[12370]: (root) BEGIN EDIT (root)
Feb 1 06:50:32 solgd9112 crontab[12370]: (root) REPLACE (root)
Feb 1 06:50:32 solgd9112 crontab[12370]: (root) END EDIT (root)
Feb 1 06:52:09 solgd9112 PAM-unix2[12365]: session finished for user root, service su
Feb 1 07:21:15 solgd9112 -- MARK --
Feb 1 07:35:41 solgd9112 crontab[12382]: (root) LIST (root)
Feb 1 07:36:27 solgd9112 cron[12389]: (CRON) STARTUP (fork ok)
Feb 1 07:59:00 solgd9112 CRON[12433]: (root) CMD ( rm -f /var/spool/cron/lastrun/cron.hourly)
Feb 1 08:00:02 solgd9112 su: (to nobody) root on none
Feb 1 08:00:02 solgd9112 PAM-unix2[12658]: session started for user nobody, service su
Feb 1 08:00:07 solgd9112 PAM-unix2[12658]: session finished for user nobody, service su
Feb 1 08:21:15 solgd9112 -- MARK --
Feb 1 08:41:15 solgd9112 -- MARK --
Feb 1 08:59:00 solgd9112 CRON[12775]: (root) CMD ( rm -f /var/spool/cron/lastrun/cron.hourly)
Feb 1 09:21:15 solgd9112 -- MARK --


Dann wurde der Cron-Prozess gekillt und neu gestartet.
Man sieht wieder Cron-Activitäten. Das aktuelle Datum ist 01.02.2005.
Morgen früh werden wir sicher eine Sicherung vorfinden.

Das versteht doch keiner, oder?

Außerdem noch eine Bemerkung zu unserem Dummy-Eintrag in der Crotab.
Als wir das "nagelneue" System sofort mit einem Cron-Eintrag versehen haben, wurde der Auftrag nicht ausgeführt, erst nach dem Nachrüsten mit diesem ominösen Dummy-Eintrag.

Nisi

Natürlich hat gestern Abend wieder alles funktioniert ;-).

Feb 1 22:00:00 solgd9112 CRON[14679]: (root) CMD (/usr1/kommandos/cron-si01)
Feb 1 22:00:01 solgd9112 kernel: sym53c1010-66-0-<5,*>: FAST-10 WIDE SCSI 20.0 MB/s (100.0 ns, offset 15)
Feb 1 22:00:02 solgd9112 su: (to oracle) root on none
Feb 1 22:00:02 solgd9112 PAM-unix2[14729]: session started for user oracle, service su
Feb 1 22:00:08 solgd9112 PAM-unix2[14729]: session finished for user oracle, service su
Feb 1 22:00:08 solgd9112 su: (to oracle) root on none
Feb 1 22:00:08 solgd9112 PAM-unix2[14763]: session started for user oracle, service su
Feb 1 22:00:08 solgd9112 PAM-unix2[14763]: session finished for user oracle, service su
Feb 1 22:19:52 solgd9112 su: (to oracle) root on none
Feb 1 22:19:52 solgd9112 PAM-unix2[14859]: session started for user oracle, service su
Feb 1 22:20:17 solgd9112 PAM-unix2[14859]: session finished for user oracle, service su
Feb 1 22:20:17 solgd9112 su: (to oracle) root on none
Feb 1 22:20:17 solgd9112 PAM-unix2[14919]: session started for user oracle, service su
Feb 1 22:20:18 solgd9112 PAM-unix2[14919]: session finished for user oracle, service su

Aber woran liegt es?
Macke am Linux Betriebssystem?

Nisi

Jemand noch eine Idee?

Nisi