reboot 4.11 trval skoro 2 hodiny

[Miroslav Lachman]

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 ;-) )
> 
>     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).
> 
>     Ja osobne bych podezrival ten sync ...
> 
>                     Dan

Asi to byl ten sync. Kdyz jsem se pred rebootem dival na fstat, tak 
`fstat | grep httpd | wc -l` vracelo cislo okolo 13 000, sice moc presne 
nevim, co to znamena (jestli je to nejaky extrem, nebo je to bezne), ale 
ted mi ten samy prikaz vraci okolo 700, takze na mem serveru to extrem 
kazdopadne byl.
Nicmene jsem tedy vubec netusil, ze reboot (ukonceni) muze trvat takhle 
dlouho. Mel jsem za to, ze tam je par timeoutu pro ruzne oblasti 
ukoncovani systemu, ale ze to v souctu nikdy nepresahne par minut.
Od toho rebootu bezi zase system zcela normalne, takze to snad nebyl 
zadny vadny HW.