Am 21.04.2015 um 07:41 schrieb Joerg Thuemmler:
Am 20.04.2015 19:19, schrieb Richard Kraut:
Am Montag, den 20.04.2015, 09:24 +0200 schrieb Joerg Thuemmler:
SMART Tests OK für beide Platten eines Areca-RAIDs 1) bleibt beim booten
hängen.
Speichertest mit 'memtest' auch OK?
ja, war er zumindest mal vor ein paar Wochen. Da auch speicherfressende
Anwendungen keinen Ärger machen, halte ich da Probleme für
unwahrscheinlich.
Er rebootet regelmäßig 23:35 Uhr nachts.
Wird hier etwas via Cron gestartet oder wurde kurz zuvor ein Cronjob
aktiv?
na, der reboot halt...
Apr 20 05:27:46 linux kernel: Kernel logging (proc) stopped.
Apr 20 05:27:46 linux rsyslogd: [origin software="rsyslogd"
swVersion="5.6.5" x-pid="2285" x-info="http://www.rsyslog.com"]
exiting on
Apr 20 05:27:46 linux kernel: imklog 5.6.5, log source = /proc/kmsg
started.
Apr 20 05:27:46 linux rsyslogd: [origin software="rsyslogd"
swVersion="5.6.5" x-pid="3377" x-info="http://www.rsyslog.com"] start
Logrotate kann den rsyslog anhalten um seine Aufgabe zu erfüllen. Danach
sollte rsyslog weiter laufen.
da könntest Du recht haben, dass das das Logrotate ist, würde evt.
passen, direkt klar gefunden habe ich das in /etc/rc.d/syslog zwar
nicht, könnte aber irgendwo implizit dabei sein...
Aber sofern der Hänger bzw. Neustart regelmäßig immer zu nahezu der
selben Uhrzeit passiert, würde ich, wie oben bereits erwähnt, mal
schauen, was die Kiste denn da so macht.
Hallo und Danke,
der Neutstart wird vom cron gestartet, ist ja gewollt so. Aber seit
Anfang des Jahre ist er halt manchmal im booten hängengeblieben, vorher
nie...
Er hing halt nach dem LAN-Start... ohne weiteren messages-Eintrag o.ä.
Es ist auch kein Absturz, Kernel und alles, was bis dahin gestartet
wurde, läuft ja (weil er ja zumindest weiterloggt - die gelegentlichen
Netzwerkkartenstörungen).
Im Test ist er halt nie hängengeblieben und heute Nacht auch nicht...
cu jth
Hi,
an diesem WE ist es wieder mal passiert: Nach dem reboot hängt das
System in irgendeiner Aktivität rum, loggt keine Fehler, startet aber
auch nicht vollständig. Der Kernel scheint korrekt oben zu sein, denn
boot.omsg ist soweit vollständig:
...
<6>[ 12.898366] EXT4-fs (sda5): mounted filesystem with ordered data
mode. Opts: acl,user_xattr
Kernel logging (ksyslog) stopped.
Kernel log daemon terminating.
Interessanterweise geht es dann weiter mit:
Boot logging started on /dev/tty1(/dev/console) at Mon Sep 28 06:08:44 2015
Master Resource Control: previous runlevel: 3, switching to runlevel: 0
Master Resource Control: Running /etc/init.d/before.local
done
service smb start
...
Shutting down Samba SMB daemon Warning: daemon not running. done
service smb done service cups start
Shutting down acpid done
sieht ein wenig so aus, als wäre - nach dem hier eine Kollegin um 6:08
den Power-Knopf gedrückt hat, einerseits der "alte" Boot vom Freitag mit
before.local fortgesetzt worden, gleichzeitig aber ein Switch auf
Runlevel 0 (durch den Druck auf Power) eingeleitet. Auch im weiteren Log
gehen dann starten und stoppen von Services munter weiter.
Da ich atop mitlaufen lasse, habe ich Prozesstatistik aus der fraglichen
Zeit:
14s nach reboot:
PID SYSCPU USRCPU VGROW RGROW RDDSK WRDSK ST EXC S
CPUNR CPU CMD.
1 1.14s 0.02s 2216K 728K 294.9M 900K N- - S
3 8% init
17 0.52s 0.00s 0K 0K 0K 0K N- - S
0 4% kworker/0:1
376 0.02s 0.01s 3212K 1324K 0K 0K N- - S
2 0% udevd
960 0.02s 0.00s 1920K 596K 16K 4K N- - S
3 0% acpid
37 0.02s 0.00s 0K 0K 0K 0K N- - S
2 0% khubd
92 0.02s 0.00s 0K 0K 0K 0K N- - S
2 0% scsi_eh_5
903 0.00s 0.01s 3064K 1340K 40K 0K N- - S
2 0% rc
378 0.01s 0.00s 2944K 1204K 4756K 0K N- - S
2 0% udevd
59 0.01s 0.00s 0K 0K 0K 0K N- - S
3 0% kworker/3:1
93 0.01s 0.00s 0K 0K 0K 0K N- - S
3 0% scsi_eh_6
961 0.00s 0.00s 3088K 3076K 212K 4K N- - R
1 0% atop
925 0.00s 0.00s 2416K 2408K 564K 0K N- - D
3 0% startpar
472 0.00s 0.00s 3204K 1312K 0K 0K N- - S
1 0% udevd
10min nach reboot:
PID SYSCPU USRCPU VGROW RGROW RDDSK WRDSK ST EXC S
CPUNR CPU CMD...
925 0.92s 0.09s 0K 0K 10324K 52K -- - S
1 0% startpar
1710 0.70s 0.03s 1932K 492K 0K 0K N- - S
0 0% startproc
1515 0.30s 0.00s 1936K 396K 140K 12K N- - S
3 0% ifplugd
1118 0.06s 0.06s 11032K 5780K 5572K 20K N- - S
3 0% cupsd
17 0.11s 0.00s 0K 0K 0K 0K -- - S
0 0% kworker/0:1
1057 0.03s 0.06s 0K 0K - - NE 0 E
- 0% <hwinfo>
1760 0.08s 0.00s 0K 0K 0K 0K N- - S
0 0% kworker/0:0
1031 0.03s 0.03s 0K 0K - - NE 0 E
- 0% <kbd>
1388 0.02s 0.03s 0K 0K - - NE 0 E
- 0% <ifup>
1518 0.01s 0.03s 0K 0K - - NE 0 E
- 0% <ifup>
1713 0.02s 0.01s 10640K 2040K 316K 308K N- - S
3 0% nmbd
1085 0.01s 0.02s 3324K 1620K 460K 44K N- - S
3 0% network
15 0.00s 0.03s 0K 0K 0K 0K -- - S
1 0% rcuc1
961 0.01s 0.01s 232K 232K 24K 8K -- - R
1 0% atop
1598 0.00s 0.02s 3324K 1536K 0K 8K N- - S
2 0% ifup
Danach bleibt das so, mal abgesehen davon, dass VGROW, RGROW und
RDDISK/WRDISK 0 oder sehr klein sind. Irgendwie bin ich ratlos. Wer
stirbt hier ab und verhindert den vollständigen Start. Im Runlevel 3
kommt nach S02network S03local. Da werden einige eigene Scripte und
Daemons gestartet, ich würde mich da sofort für schuldig erklären, aber
es verwundert mich dann halt wieder, das cupsd läuft, der startet mit
S08cupsd, also defintiv danach, dito auch nmbd (S04). Und es gibt auch
kein rc-Script mit # Required-Start: ($)local...
AFAIK werden doch die rc-Scripte in der Reihenfolge der S-Nummern (und
bei gleicher parallel) abgearbeitet?
Wenn z.B. S02network zwar abgearbeitet ist, aber aus irgendeinem Grunde
trotzdem kein Netzwerk da ist, warten dann alle Scripte, bei denen
# Required-Start: $network
im Header steht? Und gibt es einen Unterschied, wenn da "$network" oder
"network" steht? $network könnte ja eine Variable sein, aber ich sehe
nicht, wo sie belegt wird, weder in /etc/rc.d/rc noch in
/etc/rc.d/network jedenfalls IMHO.
Ich werde jetzt mal an allen möglichen Stellen kleine Loganweisungen mit
Timestamps einbauen, vielleicht sehe ich, wenn es das nächste Mal
passiert, wer da blockt.
Sehr merkwürdig...
--
www.teddylinx.de
--
Um die Liste abzubestellen, schicken Sie eine Mail an:
opensuse-de+unsubscribe@opensuse.org
Um den Listen Administrator zu erreichen, schicken
Sie eine Mail an: opensuse-de+owner@opensuse.org