Boot hängt bei OS11.4 evergreen
Hi, nachdem es nun zum dritten Mal, aber nicht reproduzierbar passiert ist: mein OS11.4ever Serverlein (AMD Phenom II X4 955 Processor, 8GB RAM, Kernel 3.0.101-99-desktop, mindestens 40% auf jeder Partition frei, SMART Tests OK für beide Platten eines Areca-RAIDs 1) bleibt beim booten hängen. Er rebootet regelmäßig 23:35 Uhr nachts. Es gibt keine Fehlermeldungen (warn, messages...). In den messages ist der letzte Eintrag beim booten: Apr 17 23:37:49 linux ifup: IP address: 192.168.0.1/24.. Apr 17 23:37:49 linux ifup:.. Apr 17 23:37:50 linux ifplugd(eth0)[2739]: Program executed successfully. Apr 17 23:37:51 linux kernel: [ 47.038214] r8169 0000:07:00.0: eth1: link up Apr 17 23:37:51 linux kernel: [ 47.038582] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready danach läuft zumindest ein rudimentäres System, denn die messages enthalten dann einige: Apr 18 05:30:26 linux ifplugd(eth0)[2739]: Link beat lost. Apr 18 05:30:27 linux ifplugd(eth0)[2739]: Link beat detected. Ein funktionierender Boot setzt nach dem Netzwerk oben fort mit: 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 Apr 20 05:27:46 linux sshd[3539]: Server listening on 0.0.0.0 port 22. Leider hat meine Vertretung nicht gewusst, dass man mit ESC den Splashscreen abschalten kann, so dass ich nicht weiß, was der Bildschirm gezeigt hat (habe das gleich mal in der Bootzeile geändert). Ich bin etwas ratlos. Es scheint immer mal bugs mit syslog gegeben zu haben, aber die haben wohl nur den Ausfall des Loggings, aber keinen Boothänger verursacht... Ein simpler Netzwerkverbindungsfehler (kein DSL oder so) stoppt doch aber auch keinen Boot? Nachdem das das letzte Mal passiert ist (vor 3 Wochen), habe ich die Kiste gefühlt 20x rebootet, kaltgestartet, hart den Strom abgeschaltet und nach dem Wiedereinschalten booten lassen, die USV bis in den Shutdown gehen lassen ... nix. Immer korrekt gebootet... Jeder Tipp ist willkommen... cu jth -- 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
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?
Er rebootet regelmäßig 23:35 Uhr nachts.
Wird hier etwas via Cron gestartet oder wurde kurz zuvor ein Cronjob aktiv?
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. 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. -- MfG Richi
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 -- 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
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 <notice -- Sep 28 06:08:44.987804000> service smb start ... Shutting down Samba SMB daemon Warning: daemon not running. done <notice -- Sep 28 06:08:45.55976000> service smb done<notice -- Sep 28 06:08:45.56148000> 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
Am 28.09.2015 um 10:53 schrieb Joerg Thuemmler:
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 <notice -- Sep 28 06:08:44.987804000> service smb start ... Shutting down Samba SMB daemon Warning: daemon not running. done <notice -- Sep 28 06:08:45.55976000> service smb done<notice -- Sep 28 06:08:45.56148000> 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...
Hi, nachdem ich ein reichlich halbes Jahr Ruhe davor hatte, hat es heute wieder zugeschlagen, gleiche Situation, gleicher Stoppunkt. Der reboot wird korrekt gestartet, System fährt herunter, startet wieder und die letzten Messages sind diese: May 17 22:37:17 linux ifup: IP address: 192.168.0.1/24 May 17 22:37:17 linux ifup: May 17 22:37:17 linux ifplugd(eth0)[1516]: Program executed successfully. May 17 22:37:19 linux kernel: [ 16.447805] r8169 0000:07:00.0: eth1: link up May 17 22:37:19 linux kernel: [ 16.448132] ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready ... hier würde es normalerweise weitergehen mit May 16 22:37:18 linux kernel: Kernel logging (proc) stopped. May 16 22:37:18 linux rsyslogd: [origin software="rsyslogd" swVersion="5.6.5" x-pid="1046" x-info="http://www.rsyslog.com"] exiting o May 16 22:37:19 linux kernel: imklog 5.6.5, log source = /proc/kmsg started. May 16 22:37:19 linux rsyslogd: [origin software="rsyslogd" swVersion="5.6.5" x-pid="2228" x-info="http://www.rsyslog.com"] start May 16 22:37:19 linux sshd[2285]: Server listening on 0.0.0.0 port 22. ... (Zeilen aus dem log vom Vortag) heute ist aber das das nächste: May 18 03:47:09 linux ifplugd(eth0)[1516]: Link beat lost. May 18 03:47:10 linux ifplugd(eth0)[1516]: Link beat detected. (kommt immer mal, scheint aber sonst keine Bedeutung zu haben?, aber der Netzwerkkartentreiber ist zumindest da), aber das logrotate scheint gar nicht mehr gestartet zu werden? Früh drückt dann jemand den Powerknopf, die Kiste fährt runter und beim nächsten Drücken bootet sie korrekt: May 18 06:17:01 linux polkitd[3305]: started daemon version 0.99 using authority implementation `local' version `0.99' May 18 06:17:01 linux pm-profiler: Power Button pressed, executing /sbin/shutdown -h now May 18 06:17:01 linux shutdown[3310]: shutting down for system halt May 18 06:17:01 linux init: Switching to runlevel: 0 May 18 06:17:03 linux kernel: Kernel logging (proc) stopped. May 18 06:17:03 linux rsyslogd: [origin software="rsyslogd" swVersion="5.6.5" x-pid="1024" x-info="http://www.rsyslog.com"] exiting o May 18 06:19:48 linux kernel: imklog 5.6.5, log source = /proc/kmsg started. May 18 06:19:48 linux rsyslogd: [origin software="rsyslogd" swVersion="5.6.5" x-pid="962" x-info="http://www.rsyslog.com"] start May 18 06:19:48 linux kernel: [ 99.757017] powernow-k8: Found 1 AMD Phenom(tm) II X4 955 Processor (4 cpu cores) (version 2.20.00) ... ziemlich ratlos.... ;-( Thx für jeden Hinweis cu jth -- 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
participants (2)
-
Joerg Thuemmler -
Richard Kraut