reboot 4.11 trval skoro 2 hodiny
Divacky Roman
xdivac02 at stud.fit.vutbr.cz
Fri Sep 2 11:57:48 CEST 2005
On Thu, Sep 01, 2005 at 07:49:37PM +0200, Dan Lukes wrote:
> Divacky Roman wrote:
> >>Aug 31 15:01:55 home reboot: rebooted by quip
> >>Aug 31 15:01:55 home syslogd: exiting on signal 15
> >>Aug 31 16:42:19 home /kernel: Copyright (c) 1992-2005 The FreeBSD Project.
> >>Aug 31 16:42:19 home /kernel: Copyright (c) 1979, 1980, 1983, 1986,
> >>1988, 1989, 1991, 1992, 1993, 1994
> >>Aug 31 16:42:19 home /kernel: The Regents of the University of
> >>California. All rights reserved.
> >>Aug 31 16:42:19 home /kernel: FreeBSD 4.11-STABLE #0: Tue Feb 1
> >>20:59:35 CET 2005
> >>
> >>Pokud to nekdo nahodou prehlednul, tak se jedna o to, ze 'reboot' byl v
> >>15:01:55, ale system zacal nabihat az v 16:42:19
>
> >ten log neznamena ze ve 3 se to restartlo a o trictvrte na 5 to nabehlo...
> >to
> >znamena ze ve 3 se vypnul syslog. co se delo pak je otazka - pravdepodobne
> >se
> >cekalo az chcipne nejaky hnusny proces ;)
>
> No, pro uplnost, chcipnutim syslogu zaznamenavani hlasek nekonci (a
> ani nezacina az po jeho nabehnuti):
>
> === /var/log/messges =======
> Jun 30 13:09:15 ns reboot: rebooted by dan
> Jun 30 13:09:15 ns syslogd: exiting on signal 15
> Jun 30 13:11:00 ns /kernel: Waiting (max 60 seconds) for system process
> `vnlru' to stop...stopped
> Jun 30 13:11:00 ns /kernel: Waiting (max 60 seconds) for system process
> `bufdaemon' to stop...stopped
> Jun 30 13:11:00 ns /kernel: Waiting (max 60 seconds) for system process
> `syncer' to stop...stopped
> Jun 30 13:11:00 ns /kernel:
> Jun 30 13:11:00 ns /kernel: syncing disks...
> Jun 30 13:11:00 ns /kernel: done
> Jun 30 13:11:00 ns /kernel: Uptime: 16d4h6m26s
> Jun 30 13:11:00 ns /kernel: Rebooting...
> Jun 30 13:11:00 ns /kernel: Copyright (c) 1992-2005 The FreeBSD Project.
> ...
> Jun 30 13:11:00 ns /kernel: FreeBSD 4.11-RELEASE-p11 #4: Thu Jun 30
> 09:41:07 CEST 2005
> ===========================
>
> Zaznam techto hlasek nevyzaduje, aby aktualne bezel syslog (hle,
> kouzlo ;-) )
jak tohle funguje?
> Zbytek uvahy je pravdepodobne spravne - zrejme se tam na cosi
> opravdu dlouho cekalo. A podle chybejicich hlasek soude, bylo to divoky ...
>
> Ale asi to nebyl nejaky ledajaky proces. Vetsinu procesu strili INIT
> a tam je to casove omezeno na kern.shutdown_timeout + 2*10 sec.
>
> Jen pro zajimavost, OID kern.shutdown_timeout ve skutecnosti
> neexistuje, takze se pouzije fall-back hodnota 120s.
>
> Pote by mely zbyvat vyhradne systemove procesy (kazdy ma na svuj
> shutdown cas kern.shutdown.kproc_shutdown_wait tedy typicky 60s), sync
> disku (ten sice ma omezeny cas, ale nelze ho snadno vycislit) a celkove
> shutdown komponent jadra (ACPI, IP vrstva, SYSCONS a tak podobne).
kazdopdne to bylo neco hnusneho ;)
More information about the Users-l
mailing list