Systemstart extrem langsam

[filou]

Hallo,

ich benutze hier einen Rechner mit Sarge und nem Backport von xorg. IDE Festplatte, Celeron CPU.

Sobald ich den Rechner starte, wird der Kernel ordentlich geladen. Sobald aber z.B. syslogd gestartet wird, hängt die Kiste. Für den Syslog mal mindestens 1 Minute. Danach geht es weiter, hängt dann aber wieder bei exim oder portmap.

Schlussendlich startet der Rechner zwar bis zum Login, der Vorgang dauert aber ewig lange.

Hat evtl. die Festplatte einen Knacks ?

Hat so etwas jemand schomal beobachtet ? Hinweise, Vorschläge ??

mfg

[nepos]

Sowas kann auch auftreten, wenn was mit der Namensaufloesung nicht klappt bzw. falsch konfiguriert ist. Dann warten bestimmte Prozesse, z.B. Exim auch mal ne Minute bis se in einen Timeout gelaufen sind...

[Phex]

Habe seit gestern das gleiche Problem.
@nepos: Was meinst du mit Namensauflösung?
Thx for help.

-> Meine /var/log/syslog -Datei war auf satte 2GB angewachsen. Mittels ">/var/log/syslog" habe ich diese Datei geleert und der Systemstart verlief wieder einwandfrei.
Weiß jemand warum die Datei so groß geworden ist und wie ich dem in Zukunft vorbeugen kann?

[nepos]

Wenn du z.B. in der /etc/resolv.conf Mist stehen hast, kann es passieren, dass bestimmte Dienste darueber eine Namenslaufloesung machen wollen. Was dann natuerlich nicht klappt, wenn da Mist drin steht. Dann laufen diese Dienste irgendwann in nen Timeout und das dauert dann halt.

@Phex: Puh, kann man so nicht sagen, da haette ich vor dem Loeschen mal nen Blick reingeworfen. Normal ist das jedenfalls nicht, dass die so gross wird. Normalerweise wird die Datei z.B. auch taeglich von logrotate rotiert. Beobacht das doch mal und schau, was da immer so reingeschrieben wird.

[Phex]

Hi! Also in meiner resolv.conf steht folgendes drin:

Code: Alles auswählen

search upce.cz
nameserver 10.0.2.66
nameserver 10.0.2.70

Ich bin an der Uni in Pardubice, CZ und dort werde ich überall per DHCP eingelogt. Die lange Wartezeit beim Starten des syslogd gab es auch, wenn das Interface gar nicht erst hochgefahren wurde, also kein Netzwerkkabel drin steckte.

Nachdem ich die syslog ja heute früh nun geleert hatte, ist sie mittlerweile schon wieder auf 500KB angewachsen. Außerdem ist mir dabei im gleichen Verzeichnis /var/log die Datei "debug" aufgefallen, die bereits 850MB groß ist. In beiden Dateien häufen sich die Meldungen wie die folgende:

Code: Alles auswählen

May  8 10:54:49 HESINDE kernel: usb-storage: Status code 0; transferred 122880/122880
May  8 10:54:49 HESINDE kernel: usb-storage: -- transfer complete
May  8 10:54:49 HESINDE kernel: usb-storage: Bulk data transfer result 0x0
May  8 10:54:49 HESINDE kernel: usb-storage: Attempting to get CSW...
May  8 10:54:49 HESINDE kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 13 bytes
May  8 10:54:49 HESINDE kernel: usb-storage: Status code 0; transferred 13/13
May  8 10:54:49 HESINDE kernel: usb-storage: -- transfer complete
May  8 10:54:49 HESINDE kernel: usb-storage: Bulk status result = 0
May  8 10:54:49 HESINDE kernel: usb-storage: Bulk Status S 0x53425355 T 0xfc3 R 0 Stat 0x0
May  8 10:54:49 HESINDE kernel: usb-storage: scsi cmd done, result=0x0
May  8 10:54:49 HESINDE kernel: usb-storage: queuecommand called
May  8 10:54:49 HESINDE kernel: usb-storage: *** thread sleeping.
May  8 10:54:49 HESINDE kernel: usb-storage: *** thread awakened.
May  8 10:54:49 HESINDE kernel: usb-storage: Command WRITE_10 (10 bytes)
May  8 10:54:49 HESINDE kernel: usb-storage:  2a 00 00 0e d6 d8 00 00 f0 00
May  8 10:54:49 HESINDE kernel: usb-storage: Bulk Command S 0x43425355 T 0xfc4 L 122880 F 0 Trg 0 LUN 0 CL 10
May  8 10:54:49 HESINDE kernel: usb-storage: usb_stor_bulk_transfer_buf: xfer 31 bytes
May  8 10:54:49 HESINDE kernel: usb-storage: Status code 0; transferred 31/31
May  8 10:54:49 HESINDE kernel: usb-storage: -- transfer complete
May  8 10:54:49 HESINDE kernel: usb-storage: Bulk command transfer result=0
May  8 10:54:49 HESINDE kernel: usb-storage: usb_stor_bulk_transfer_sglist: xfer 122880 bytes, 23 entries
May  8 10:54:49 HESINDE kernel: ieee1394: received packet: ffc10910 ffc0ffff 00000000 00080000
May  8 10:54:49 HESINDE kernel: ieee1394: send packet at S400: ffc00920 ffc10000 00000000
May  8 10:54:49 HESINDE kernel: ieee1394: send packet at S400: ffc09510 ffc1ffff f0100008 00080000
May  8 10:54:49 HESINDE kernel: ieee1394: received packet: ffc19520 ffc00000 00000000
May  8 10:54:49 HESINDE kernel: ieee1394: received packet: ffc10910 ffc0ffff 00000000 00080000
May  8 10:54:49 HESINDE kernel: ieee1394: send packet at S400: ffc00920 ffc10000 00000000
May  8 10:54:49 HESINDE kernel: ieee1394: send packet at S400: ffc09910 ffc1ffff f0100008 00080000
May  8 10:54:49 HESINDE kernel: ieee1394: received packet: ffc19920 ffc00000 00000000

Ist es sinnvoll aus dem Kernel die Debug-Messages rauszunehmen? Schafft das Abhilfe oder ist die Ursache woanders begraben?

[filou]

Hallo,

also bei mir war es wohl tatsächlich ein Plattendefekt

Der Systemstart hat immer wieder an unterschiedlichen Stellen gehangen. Schlußendlich war auch im laufenden Betrieb ein Haken zu verspühren.

Habe auf einen neuen Platte das Backup draufgezogen -> gleiche Konfig, keine Probleme.

[pr0pa]

@Phex
du kannst ja mal versuchen die Debug Messages für das USB(storage)-Zeugs und evtl das für Firewire rauszunehmen, das scheint ja die Masse zu sein ..

testweise könntest du ( falls das mit der Namensauflösung zu tun hat ) einen anderen DNS-Server in deine resolf.conf eintragen

meine : /etc/resolf.conf :

Code: Alles auswählen

search 145.253.2.81
nameserver 145.253.2.81

das ist der DNS-Server von Arcor, kann sein, daß dann bei dir die Namensauflösung nicht ganz so schnell ist wie bei mir. Günstig wäre die IP von dem DNS-Server deiner Uni.
Oder sind das schon die IP's der Server ? Sehen ein bissl komisch aus finde ich.

Grüße
Marian

[Phex]

Also nach 14-tägiger Beobachtung warens bei mir wirklich die debug-messages für USB und FW aus dem Kernel gewesen, die bei mir die log-Dateien enorm anwachsen ließen. Jetzt funzt es wieder...