reboot 4.11 trval skoro 2 hodiny

[Dan Lukes]

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