сервер после перезагрузки не работает

В смысле, в логе пишет, что ушёл на ребут, но перезагрузка не происходит?

Какая железка?

Какая ось?

Что в биосе написано про APIC и про ACPI?

[umka], В смысле, в логе пишет, что ушёл на ребут, но перезагрузка не происходит?"

да, видимо, так и происходит...

вот лог:

"Dec 30 14:00:01 ouvre /USR/SBIN/CRON[6770]: (root) CMD ( shutdown -r now)

Dec 30 14:00:01 ouvre shutdown[6770]: shutting down for system reboot

Dec 30 14:00:01 ouvre init: Switching to runlevel: 6

Dec 30 14:00:03 ouvre mysqld[2666]: 091230 14:00:03 [Note] /usr/sbin/mysqld: Normal shutdown

Dec 30 14:00:03 ouvre mysqld[2666]:

Dec 30 14:00:03 ouvre mysqld[2666]: 091230 14:00:03 [ERROR] /usr/sbin/mysqld: Sort aborted

Dec 30 14:00:07 ouvre mysqld[2666]: 091230 14:00:07 InnoDB: Starting shutdown...

Dec 30 14:00:08 ouvre mysqld[2666]: 091230 14:00:08 InnoDB: Shutdown completed; log sequence number 0 43665

Dec 30 14:00:09 ouvre mysqld[2666]: 091230 14:00:09 [Note] /usr/sbin/mysqld: Shutdown complete

Dec 30 14:00:09 ouvre mysqld[2666]:

Dec 30 14:00:09 ouvre mysqld_safe[6849]: ended

Dec 30 14:00:09 ouvre dovecot: Killed with signal 15

Dec 30 14:00:10 ouvre named[2291]: received control channel command 'stop -p'

Dec 30 14:00:10 ouvre named[2291]: shutting down: flushing changes

Dec 30 14:00:10 ouvre named[2291]: stopping command channel on 127.0.0.1#953

Dec 30 14:00:10 ouvre named[2291]: stopping command channel on ::1#953

Dec 30 14:00:10 ouvre named[2291]: no longer listening on ::#53

Dec 30 14:00:10 ouvre named[2291]: no longer listening on 127.0.0.1#53

Dec 30 14:00:10 ouvre named[2291]: no longer listening on 213.239.213.143#53

Dec 30 14:00:10 ouvre named[2291]: no longer listening on 78.46.164.56#53

Dec 30 14:00:10 ouvre named[2291]: exiting

Dec 30 14:00:12 ouvre kernel: Kernel logging (proc) stopped.

Dec 30 17:44:39 ouvre kernel: imklog 3.18.6, log source = /proc/kmsg started.

Dec 30 17:44:39 ouvre kernel: [ 0.000000] Initializing cgroup subsys cpuset

Dec 30 17:44:39 ouvre kernel: [ 0.000000] Initializing cgroup subsys cpu

"

в 17.44 сделал hard reset.

железо

AMD Athlon 64 X2 5600+ Dual Core, 4 GB DDR2 RAM, 2 x 400 GB SATA II (Software RAID 1)

ось Debian 5.

не нашел, как можно посмотреть bios через ssh :(

root добавил 31.12.2009 в 01:22

вот

dmesg | grep -i apic

[ 0.000000] Using APIC driver default

[ 0.000000] ACPI: APIC DDFD0390, 005C (r1 M S I OEMAPIC 10000731 MSFT

97)

[ 0.000000] Detected use of extended apic ids on hypertransport bus

[ 0.000000] ACPI: Local APIC address 0xfee00000

[ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)

[ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)

[ 0.000000] ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])

[ 0.000000] IOAPIC[0]: apic_id 2, version 33, address 0xfec00000, GSI 0-23

[ 0.000000] Enabling APIC mode: Flat. Using 1 I/O APICs

[ 0.000000] mapped APIC to ffffb000 (fee00000)

[ 0.000000] mapped IOAPIC to ffffa000 (fec00000)

[ 0.106885] ENABLING IO-APIC IRQs

[ 0.107101] ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1

[ 0.249572] ACPI: Using IOAPIC for interrupt routing

dmesg | grep -i acpi

[ 0.000000] BIOS-e820: 00000000ddfd0000 - 00000000ddfde000 (ACPI data)

[ 0.000000] BIOS-e820: 00000000ddfde000 - 00000000de000000 (ACPI NVS)

[ 0.000000] ACPI: RSDP 000F98A0, 0014 (r0 ACPIAM)

[ 0.000000] ACPI: RSDT DDFD0000, 003C (r1 M S I OEMRSDT 10000731 MSFT 97)

[ 0.000000] ACPI: FACP DDFD0200, 0084 (r2 M S I OEMFACP 10000731 MSFT 97)

[ 0.000000] ACPI: DSDT DDFD0430, 40D9 (r1 1ADNC 1ADNC000 0 INTL 20051117)

[ 0.000000] ACPI: FACS DDFDE000, 0040

[ 0.000000] ACPI: APIC DDFD0390, 005C (r1 M S I OEMAPIC 10000731 MSFT 97)

[ 0.000000] ACPI: MCFG DDFD03F0, 003C (r1 M S I OEMMCFG 10000731 MSFT 97)

[ 0.000000] ACPI: OEMB DDFDE040, 0060 (r1 M S I AMI_OEM 10000731 MSFT 97)

[ 0.000000] ACPI: EPTH DDFD4510, 0038 (r1 M S I OEMHPET 10000731 MSFT 97)

[ 0.000000] ACPI: SSDT DDFD4550, 02CC (r1 A M I POWERNOW 1 AMD 1)

[ 0.000000] ACPI: PM-Timer IO Port: 0x808

[ 0.000000] ACPI: Local APIC address 0xfee00000

[ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)

[ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)

[ 0.000000] ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])

[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)

[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)

[ 0.000000] ACPI: IRQ0 used by override.

[ 0.000000] ACPI: IRQ2 used by override.

[ 0.000000] ACPI: IRQ9 used by override.

[ 0.000000] Using ACPI (MADT) for SMP configuration information

[ 0.101080] ACPI: Core revision 20080321

[ 0.240015] ACPI: bus type pci registered

[ 0.244015] ACPI: EC: Look up EC in DSDT

[ 0.249336] ACPI: Interpreter enabled

[ 0.249373] ACPI: (supports S0 S1 S3 S4 S5)

[ 0.249572] ACPI: Using IOAPIC for interrupt routing

[ 0.251803] PCI: MCFG area at e0000000 reserved in ACPI motherboard resources

[ 0.260129] ACPI: PCI Root Bridge [PCI0] (0000:00)

[ 0.260188] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]

[ 0.260393] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P1._PRT]

[ 0.260470] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCE7._PRT]

[ 0.260549] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0PC._PRT]

[ 0.272129] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 *5 7 10 11 12 14 15)

[ 0.272129] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 *7 10 11 12 14 15)

[ 0.272595] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 7 *10 11 12 14 15)

[ 0.273048] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 7 *10 11 12 14 15)

[ 0.273634] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 *4 5 7 10 11 12 14 15)

[ 0.274086] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.

[ 0.274602] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 7 10 *11 12 14 15)

[ 0.275056] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.

[ 0.276262] ACPI Warning (tbutils-0217): Incorrect checksum in table [OEMB] - 1A, should be 18 [20080321]

[ 0.276262] pnp: PnP ACPI init

[ 0.276262] ACPI: bus type pnp registered

[ 0.280262] pnp: PnP ACPI: found 13 devices

[ 0.280262] ACPI: ACPI bus type pnp unregistered

[ 0.280262] PnPBIOS: Disabled by ACPI PNP

[ 0.280262] PCI: Using ACPI for IRQ routing

[ 0.285841] ACPI: RTC can wake from S4

[ 1.355621] ACPI: PCI Interrupt 0000:00:12.0[A] -> GSI 22 (level, low) -> IRQ 22

[ 4.524596] ACPI: PCI Interrupt 0000:00:14.1[A] -> GSI 16 (level, low) -> IRQ 16

[ 5.825806] ACPI: duty_cycle spans bit 4

[ 5.825806] ACPI: ACPI0007:00 is registered as cooling_device0

[ 5.825806] ACPI: ACPI0007:01 is registered as cooling_device1

[ 6.040496] ACPI: PCI Interrupt 0000:02:00.0[A] -> GSI 19 (level, low) -> IRQ 19

[ 6.063829] ACPI: PCI Interrupt 0000:00:13.0[A] -> GSI 16 (level, low) -> IRQ 16

[ 6.237220] ACPI: PCI Interrupt 0000:00:13.1 -> GSI 17 (level, low) -> IRQ 17
[ 6.402300] ACPI: PCI Interrupt 0000:00:13.2[C] -> GSI 18 (level, low) -> IRQ 18
[ 6.600647] ACPI: PCI Interrupt 0000:00:13.3 -> GSI 17 (level, low) -> IRQ 17
[ 6.803025] ACPI: PCI Interrupt 0000:00:13.4[C] -> GSI 18 (level, low) -> IRQ 18
[ 7.004621] ACPI: PCI Interrupt 0000:00:13.5[D] -> GSI 19 (level, low) -> IRQ 19
[ 9.057406] ACPI: Power Button (FF) [PWRF]
[ 9.117919] ACPI: Power Button (CM) [PWRB]
[ 9.374872] ACPI: PCI Interrupt 0000:01:05.2 -> GSI 19 (level, low) -> IRQ 19

Более интересный вопрос - зачем вообще сервер перезагружать по крону. Предположу,

что этим делается попытка решить какую-то проблему приницпиально неверным путем.

myhand добавил 31.12.2009 в 01:30

Я думаю, kernel.panic=5 в /etc/sysctl.conf добавить вам не лишнее.

А.. сорри, забыл что у вас без квм-а.

Это плохо :)

Я бы посоветовал этими опциями в биосе поиграть (особенно ACPI).

А еще лучше - обновить ядро.

Можт гуру по debian щас еще чего-нибудь дельное подскажут :)

/А вот и они :) Кстати да, перезагружвать сервак по крону - это жестоко/

Hetzner? Я в такой ситуации выбрал manual hardware-reset, сервер загрузился.

я уже 3 года так делаю...

сервер перегружается, PID'ы становятся чистыми, идут с 1, когда сервер работает неделю, например, потом он свободно зависает и я теряю пользователей, а тут перегружается - и работа продолжает, в принципе вот для чего так делаю.

самое главное, что точно такой же сервер, только с 2 Гб, с той же осью, панелью (isp), теми же конфигами, с тем же заданием по крону нормально работает и перезагружается...

можно делать ребут вручную, но это не систематизировано и могу забыть.. а Вы как делаете?

(слышал на форумах, как меряются аптаймами, я не из таких... конечно, правильно настроенный сервер должен работать без перебоев хоть год, но когда за день сервер отдает 150 Гб и отрабатывает 300к хитов... тем более на самописных движках :) )

KM.UA, да, он самый, мне помог два раза из двух automatic hardware reset...

но проблема сейчас систематическая, ее надо решать..

root добавил 31.12.2009 в 02:06

добавил...

[umka], myhand, спасибо за советы...

Хм... так система же сама по-кругу PID-ы перебирает. И если она более-менее нагружена, то за сутки это происходит далеко не один раз ))

У меня по нескольку лет аптаймы.

[umka], понятно... попробую тогда вовсе отключить перезагрузку, посмотрю, как пойдет дело...

Странная потребность, чесслово. Система сама перебирает пиды. А упереться

в их лимит (int там вроде) - не так-то просто. Думаю, Вы все-таки неверно

идентифицировали источник проблемы.

Может железка кривая. Попробуйте включить перезагрузку при панике (см. выше, "sysctl -p" сделать не забудьте ;)) - может система крашится при ребуте, из-за проблем с ACPI такое бывает. Или попросите сменить железку. Диски воткнуть в новый сервер - дело нескольких минут.

На самых самописных. 5000k хитов, 150Gb в среднем. Движок на CGI-скриптах: парсер+perl. Аптайм с прошлого апдейта ядра (месяц или два - хз). И это не исключение - а правило.

Кроме как для обновления ядра перегружать сервер обычно незачем.

myhand, после того как прописал: kernel.panic=5

попробовал сейчас reboot. снова пропал доступ к серверу и пришлось хардворно его перегружать..

(P.S. раньше при обычном reboot все было в норме...)

снова все ок, ладно, буду просить у конторы, чтобы железо заменили...