Probleme mit Cron -> Freeze :(

[TiDschay]

Hallo zusammen,

seit dem ich vor ca. 2 Wochen von OBSD 4.1 auf 4.2 umgestiegen bin (kein Upgrade sondern eine Neuinstallation) verhällt sich die tägliche, wöchentliche und monatliche Ausführug der Cronaufträge so, dass der PC komplett einfriert.

Eine Ausgabe in Logfiles bekomme ich nicht.

Nachdem ich es zeitlich eingrenzen konnte, warum der PC bei mir jede Nacht stehen bleibt, habe ich die cron-Aufträge per Hand ausgeführt und musste dabei feststellen, dass nichts mehr funktioniert.

Um beim Beispiel "daily" zu bleiben, verhällt es sich so, dass mir noch die tägliche Statistik per eMail zugestellt wird. Danach läuft der PC noch ca. 20-30 Sekunden und friert komplett ein.

Bei der Suche im Netz, habe ich zwar einiges gefunden, jedoch nichts, was zu diesem Thema passt.

Noch zur Info:
Es ist ein neu installiertes OpenBSD 4.2, es wurden keinerlei Änderungen in den Dateien /etc/daily, weekly, monthly gemacht.
Das System ist ein 2,4 GHz Pentium mit 512 MB RAM, 2 Festplatten (20GB wd0 und 10GB wd1) Beide Platten werden durch S.M.A.R.T. überwacht.

Bevor ich jetzt eine Diskussion anleiere, wie z.B. "Es könnte dies oder jenes sein", würde mir schon eine Info helfen, wie ich den Cron-Auftrag verfolgen kann (Logfile oder ähnliches) um heraus zu finden, an welcher Stelle mein PC einfriert.

Vielen Dank,
Thomas

 

[Flex6]

das kann verschiedene Ursachen haben:
1. cron verschickt bei verfehlerhaften cron-Auftrag eine email an root
funzt warscheinlich nur wenn der cron-Auftrag ohne Unterbrechung durchgeführt wird
2. es gibt auch eine crontab/allow und deny ..Benutzer erlauben cron-Auftrag oder verbieten, wenn als root dann in allow oder wer den Auftrag ausführt oder verbieten
3. cron logt in cron.log , mal in syslog.conf schauen
4.periodic/periodic.conf und daily/weekly/monthly.local
schauen welche Aufträge ausgeführt werden.monthly.weekly,daily laufen nicht über cron sondern über periodic, über cron kann passieren das sie sich todlaufen--Prozeß nicht beendet wird
5. jeder cron-Benutzer hat ein eigenes crontab und muß angelegt werden. siehe allow/deny und Zugriffeberechtigung für cronaufträge

 

[TiDschay]

Hallo Flex6,

sorry, bin nicht immer am Rechner. Als eine Lösung habe ich nun alle cron's deaktiviert, bis ich den Fehler gefunden habe.

Nun gut, jetzt habe ich mit dem Befehl:
"umask 077; /bin/sh /etc/daily > /root/crontest1.txt"
das ganze mitloggen lassen.

In der Datei "crontest.txt" steht folgender Inhalt, bevor der PC einfriert:

OpenBSD 4.2 (GENERIC) #375: Tue Aug 28 10:38:44 MDT 2007
    deraadt@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC

11:49PM  up  7:12, 3 users, load averages: 0.11, 0.16, 0.16

Removing scratch and junk files:

Checking subsystem status:

disks:
Filesystem  1K-blocks      Used     Avail Capacity  Mounted on
/dev/wd0a    19410716    835388  17604794     5%    /
/dev/wd1i     9799530    115744   9193810     1%    /var/www

Last dump(s) done (Dump '>' file systems):


mail:
Mail queue is empty

network:
Name    Mtu   Network     Address              Ipkts Ierrs    Opkts Oerrs Colls
lo0     33208 <Link>                            8948     0     8948     0     0
lo0     33208 127/8       127.0.0.1             8948     0     8948     0     0
lo0     33208 ::1/128     ::1                   8948     0     8948     0     0
lo0     33208 fe80::%lo0/64 fe80::1%lo0           8948     0     8948     0     0
rl0     1500  <Link>      00:30:84:26:24:ba    15908     0    13302     0     0
rl0     1500  192.168.178/24 192.168.178.233      15908     0    13302     0     0
rl0     1500  fe80::%rl0/64 fe80::230:84ff:fe26:24ba%rl0    15908     0    13302     0     0
enc0*   1536  <Link>                               0     0        0     0     0


Running calendar in the background.

Denke mal, dass ich zumindest mit dieser Ausgabe nun weis, wann es hängt, jedoch noch nicht, wie ich es beheben kann.

Denn alles was danach noch in der Datei "/etc/daily" steht kann dafür in Frage kommen.
Möglicherweise ist ja hier irgendwo ein Fehler drin? Daher poste ich einfach mal den Rest der Datei. Habe leider zu wenig Ahnung und würde wohl eher das alles was danach kommt deaktivieren.

Hier der Rest:

else
        echo "Running calendar in the background."
        calendar -a &
fi

[B][COLOR="Red"]# If CHECKFILESYSTEMS is set to 1 in the environment, run fsck
# with the no-write flag.
[ "X$CHECKFILESYSTEMS" = X1 ] && {
        echo ""
        echo "Checking filesystems:"
        fsck -n | grep -v '^\*\* Phase'
}[/COLOR]
[/B]
if [ -f /etc/Distfile ]; then
        echo ""
        echo "Running rdist:"
        if [ -d /var/log/rdist ]; then
                logf=`date +%Y.%b.%e`
                rdist -f /etc/Distfile 2>&1 | tee /var/log/rdist/$logf
        else
                rdist -f /etc/Distfile
        fi
fi

sh /etc/security 2>&1 > $OUT
if [ -s $OUT ]; then
    mail -s "`hostname` daily insecurity output" root < $OUT
fi

Irgendwo indem von mir Rot markierten Bereich ist wohl der Fehler? Habe aber keine Ahnung wo und welcher.

Wenn ich dien Befehl " fsck -n | grep -v '^\*\* Phase'" in einem ssh-Terminal eingebe funktioniert dieser auch wieder.

Die Datei "/etc/Distfile" existiert nicht bei mir.

Vielen Dank, wenn noch jemand einen Tip für mich hat,
Thomas

 

[Flex6]

hast du eine periodic.conf unter /etc oder /etc/defaults

schau da mal rein und welche Dienste periodic ausführt, fsck sollte auch dort vertreten sein und kommentierst dort die Zeile daily.local aus.
Auftrag wird mit periodic daily gestartet, periodic weekly und periodic.monthly

hast du eine email vom Auftrag bekommen oder von periodic, dort steht allgemein drin was ausgeführt wird und was nicht funktioniert, Dienst oder datei nicht gefunden etc.

 

[TiDschay]

Hallo Flex6,

hast du eine periodic.conf unter /etc oder /etc/defaults

Nein, die Dateien sind bei mir nicht vorhanden, das Verzeichnis "/etc/defaults" existiert auch nicht auf dem PC.

Nachdem ich mir die "/etc/daily" nochmals vorgenommen habe, habe ich den Aufruf am Ende "sh /etc/security" auskommentiert und somit funktioniert zumindest der Bereich ohne die Einbindung der "/etc/security".

Nun werde ich mich, sofern ich in den nächsten Tagen mal etwas mehr Zeit habe (Wochenende) mal da dran machen und suchen, wo es hängt. Leider ist genau das Thema "Zeit haben" bei mir derzeitig etwas Mangelware

Danke dir trotzdem für deine Hilfe und sobald ich den Fehler gefunden habe oder noch weiter eingrenzen konnte, geb ich dir hier im Thread noch mal Bescheid.

Grüße,
Thomas