reboot 4.11 trval skoro 2 hodiny

[Divacky Roman]

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 ;)