LINUX.ORG.RU
ФорумAdmin

Crash debian 7

 , ,


0

1

Сервер выполняет роль BDC (samba 3.6.6). Работает openldap-2.4.31 как salve (мастер на PDC). Собственно, более ничего не используется из софта. Ранее машина исполняла роль PDC и принтсервера, но был куплен новый сервер и все переехало туда, сервисы, домен и т.д. Была переустановлена OC (был старенький RedHat). По техническим причинам серверу было дано имя как в прежней конфигурации и оставлен тот же IP. С вводом в эксплуатацию замечаю регулярно следующие глюки, о которых и речь. Пытался разобраться самостоятельно, но толкового ничего не вышло.

1. Демон slapd (режим логгинга stats по дефолту) просто-таки спамит rsyslog невероятным количеством сообщений. Вплоть до того, что rsyslog начинает ругаться (pid - процесс slapd)

imuxsock begins to drop messages from pid 2498 due to rate-limiting.

2. Пару раз сервак вообще крешился, последней записью в логе было

rsyslogd was huped

В консоль при этом выводился какой-то жуткий backtrace из ядра.

3. Стал разбираться с лдапом. Дело в том, что на клиентах в сети осталось много всякого мусора: сетевые принтеры с портами на прежнем серврер (а имя и ип как раз остались прежние), всевозможные ссылки и ярлыки, опять же указывающие на прежде существовашие шары. Может быть еще что-то. Например в логах лдап упорно писал, что делает поиск по базе с фильтром {displayName=laserjet}. Это такой принтер был. Причем, таких сообщений было очень много. Я потратил время, удалил все принтры и их порты на клиентах, указывавшие на этот несуществующий принтер. Сообщения прекратились. Но в логах стало появлятьс много сообщений такого типа:

SRCH base=«ou=People,dc=mydom» scope=2 deref=0 filter="(displayName=otdel)"

«otdel» - это имя шары на прежнем сервере, сейчас ее нет. Я так понимаю, что где-то на клиентах остались «закладки», ярлыки, ресенты или еще что-то.. Но почему поиск и идет в People? Сейчас сделал логгинг лдапа уровня sync. Сообщений как бы нет, но это не решает проблему.

Наконец, вопросы.

Как можно диагностировать причину креша сервра? У меня фактически есть только скрин бэктрэйса в момент падения (http://s7.uploads.ru/8FblG.jpg). В логах все глухо.

Что за такие глюки с лдапом? Смущает еще и то, что везде, где можно в конфигах сервисов я указывал в качестве URI лдапа ip PDC, вроде бы, кроме репликации и быть ничего не должно, но нет.

В дополнение скажу ,что рядом стоит сервер с очень похожей конфигурацией и лдапа и самбы и версиями софта, только ось x64, ну т.е. еще один BDC, там все ок.

★★★

Последнее исправление: cetjs2 (всего исправлений: 5)

Ответ на: комментарий от zgen

ну, как бы да, железо не новое. Аппаратный RAID5, 2Гб ОЗУ,

cpu:

Intel(R) Xeon(TM) CPU 2.66GHz, 2657 MHz

Intel(R) Xeon(TM) CPU 2.66GHz, 2657 MHz

Intel(R) Xeon(TM) CPU 2.66GHz, 2657 MHz

Intel(R) Xeon(TM) CPU 2.66GHz, 2657 MHz

keyboard:

/dev/input/event0 AT Translated Set 2 keyboard

mouse:

/dev/input/mice ImExPS/2 Generic Explorer Mouse

graphics card:

ATI Mach64 GR

storage:

Floppy disk controller

Intel 82801CA Ultra ATA Storage Controller

Intel RAID Controller

network:

eth1 Intel PRO/1000 MT Dual Port Server Adapter

eth2 Intel PRO/1000 MT Dual Port Server Adapter eth0 Intel 82557/8/9/0/1 Ethernet Pro 100

eth3 Intel 82540EM Gigabit Ethernet Controller network interface:

lo Loopback network interface

eth0 Ethernet network interface

eth1 Ethernet network interface

eth2 Ethernet network interface

eth3 Ethernet network interface

bond0 Ethernet network interface

disk:

/dev/sda Intel Host Drive #00

partition:

/dev/sda1 Partition

/dev/sda2 Partition

/dev/sda5 Partition

/dev/sda6 Partition

cdrom:

/dev/sr0 SONY CD-ROM CDU5212

usb controller:

Intel 82801CA/CAM USB Controller #1

Intel 82801CA/CAM USB Controller #2

Intel 82801CA/CAM USB Controller #3

bios:

BIOS

bridge:

Intel E7501 Memory Controller Hub

Intel E7500/E7501 Hub Interface B PCI-to-PCI Bridge

Intel 82801 PCI Bridge

Intel 82801CA LPC Interface Controller

Intel 82870P2 P64H2 Hub PCI Bridge

Intel 82870P2 P64H2 Hub PCI Bridge

hub:

Linux 3.2.0-4-686-pae uhci_hcd UHCI Host Controller

Linux 3.2.0-4-686-pae uhci_hcd UHCI Host Controller

Linux 3.2.0-4-686-pae uhci_hcd UHCI Host Controller

memory:

Main Memory

unknown:

FPU

DMA controller

PIC

Timer

Keyboard controller

/dev/lp0 Parallel controller

PS/2 Controller

Intel E7500/E7501 Host RASUM Controller

Intel E7500/E7501 Hub Interface B RASUM Controller

Intel 82801CA/CAM SMBus Controller

Intel 82870P2 P64H2 I/OxAPIC

Intel 82870P2 P64H2 I/OxAPIC

Unclassified device Unclassified device Unclassified device Unclassified device Unclassified device Unclassified device Unclassified device Unclassified device Unclassified device Unclassified device Unclassified device Unclassified device Unclassified device

/dev/ttyS0 16550A

/dev/ttyS1 16550A

/dev/sg2 ESG-SHV SCA HSBP M15

conalex ★★★
() автор топика

Это не ldap точно, userspace программа не может загнать ядро в kernel panic.

Настрой сислог на внешний сервер, получишь полную трассировку, а не только последнюю страницу.

Yur4eg ★★
()
Ответ на: комментарий от zgen

Последовал совету Yur4eg, настроил сислог на внешний сервер. Ждем.

zgen, т.е. теперь ждать какого-то фикса в ядре нужно? Или что? С такой ситуацией впервые сталкиваюсь.

conalex ★★★
() автор топика
Ответ на: комментарий от zgen

Да, конечно, вы правы.

Еще немного отладочной информации, может быть это позволит правильно выбрать направление поиска.

Сегодня случился очередной креш. Сообщения из логов на удаленном сервере:

Nov 21 09:28:37 debian-ac kernel: imklog 5.8.11, log source = /proc/kmsg started.

Nov 21 14:34:43 debian-ac kernel: [109098.917994] program smartctl is using a deprecated SCSI ioctl, please convert it to SG_IO

Nov 21 14:34:43 debian-ac kernel: [109098.918182] program smartctl is using a deprecated SCSI ioctl, please convert it to SG_IO

Nov 21 14:35:01 debian-ac kernel: [109116.885761] program smartctl is using a deprecated SCSI ioctl, please convert it to SG_IO

Nov 21 14:35:01 debian-ac kernel: [109116.885964] program smartctl is using a deprecated SCSI ioctl, please convert it to SG_IO

Nov 21 14:35:01 debian-ac kernel: [109116.886141] program smartctl is using a deprecated SCSI ioctl, please convert it to SG_IO

Nov 21 14:35:01 debian-ac kernel: [109116.886176] GDT-HA 0: Unknown SCSI command 0x4d to cache service !

Nov 21 14:35:01 debian-ac kernel: [109116.886209] program smartctl is using a deprecated SCSI ioctl, please convert it to SG_IO

Nov 22 02:42:43 debian-ac kernel: [152779.740998] BUG: unable to handle kernel paging request at fff7f000

Т.е. упало ночью.

При загрузке было выведено предупреждение

CPU1 not responding

Одно из ядер отвалилось. Система загрузилась на оставшихс 3-х ядрах и спустя какое-то время последовал креш:

Nov 22 08:57:32 debian-ac kernel: [ 4363.825947] BUG: unable to handle kernel paging request at fff93000

Nov 22 08:57:32 debian-ac kernel: [ 4363.825973] IP: [<f8401675>] gdth_copy_internal_data+0xca/0x14a [gdth]

Nov 22 08:57:32 debian-ac kernel: [ 4363.825998] *pdpt = 0000000001485001 *pde = 00000000019fb067 *pte = 0000000000000000

Nov 22 08:57:32 debian-ac kernel: [ 4363.826022] Oops: 0002 [#1] SMP

Nov 22 08:57:32 debian-ac kernel: [ 4363.826037] Modules linked in: ppdev lp nfsd nfs nfs_acl auth_rpcgss fscache lockd sunrpc bonding loop iTCO_wdt iTCO_vendor_support intel_rng psmouse parport_pc parport i2c_i801 e7xxx_edac i2c_core processor container edac_core pcspkr shpchp rng_core button evdev serio_raw thermal_sys ext4 crc16 jbd2 mbcache sd_mod crc_t10dif sg sr_mod cdrom ata_generic gdth ata_piix libata scsi_mod e1000 e100 mii floppy uhci_hcd ehci_hcd usbcore usb_common [last unloaded: scsi_wait_scan]

Nov 22 08:57:32 debian-ac kernel: [ 4363.826237]

Nov 22 08:57:32 debian-ac kernel: [ 4363.826245] Pid: 26680, comm: smartctl Not tainted 3.2.0-4-686-pae #1 Debian 3.2.51-1 Intel Corporation SE7501CW2 /SE7501CW2 Board

Nov 22 08:57:32 debian-ac kernel: [ 4363.826274] EIP: 0060:[<f8401675>] EFLAGS: 00210086 CPU: 2

Nov 22 08:57:32 debian-ac kernel: [ 4363.826289] EIP is at gdth_copy_internal_data+0xca/0x14a [gdth]

Nov 22 08:57:32 debian-ac kernel: [ 4363.826302] EAX: fff92ff0 EBX: ebf59680 ECX: 00000014 EDX: 4e785163

Nov 22 08:57:32 debian-ac kernel: [ 4363.826315] ESI: eb8c3c20 EDI: fff93000 EBP: 00200086 ESP: eb8c3b60

Nov 22 08:57:32 debian-ac kernel: [ 4363.826328] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068

Nov 22 08:57:32 debian-ac kernel: [ 4363.826341] Process smartctl (pid: 26680, ti=eb8c2000 task=f70a5560 task.ti=eb8c2000)

Nov 22 08:57:32 debian-ac kernel: [ 4363.826355] Stack:

Nov 22 08:57:32 debian-ac kernel: [ 4363.826361] 00004242 00000024 00000000 ffff0003 ffff000a ffff0024 00000000 ffffffff

Nov 22 08:57:32 debian-ac kernel: [ 4363.826406] eb8c3c20 00000024 eb8c3c10 c00803bc 00010000 00000024 00000000 c00834b8

Nov 22 08:57:32 debian-ac kernel: [ 4363.826456] 00000001 c00803bc f8402ba0 00000024 eb8c3c20 f8408206 00000000 00000000

Nov 22 08:57:32 debian-ac kernel: [ 4363.826507] Call Trace:

Nov 22 08:57:32 debian-ac kernel: [ 4363.826528] [<f8402ba0>] ? gdth_next+0x620/0x8fe [gdth]

...

При последкующей загрузке опять

CPU1 not responding

Я намеренно перезагрузился еще раз и тогда уже этого сообщения не было. Все 4 ядра инициализировались. Пока работает.

conalex ★★★
() автор топика
Ответ на: комментарий от conalex

Итак, что в итоге получилось. Логи крешей заставили грешить на gdth - модуль ядра, работающий с итнеловским raid-контроллером. В сервере торчит этот контроллер, все винты висят на нем в виде raid-5. Диагностика самого контроллера штатными средствами биоса проблем не выявила, винты и массив в порядке. Попытки подсунуть «родной» модуль gdth из поставки железа не увенчались успехом, исходники драйвера скомпилить не получилось, да и версия модуля в поставке занчительно старше той, что идет с ядром 3.2.0-4 (что ставится с дебианом 7). Не придумал ничего лучше, как собрать свежее ядро 3.12.0 и грузиться с ним. Отличие - gdth в версии поновее, работает не как модуль, а вкомпилен в ядро. Попутно fsck выявил и устранил несколько ошибок на диске. Нагрузку на машину довел до нужного уровня, две недели - полет нормальный.

conalex ★★★
() автор топика
1 марта 2014 г.
Ответ на: комментарий от conalex

Спасибо за то, что уделил время и отписался.

minakov ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.