Debian 6.0.6 squeeze на сервере виснет намертво!

[yura3d]

Здравствуйте!
В последнее время столкнулся с проблемой, на сервере постоянно виснет Debian, при этом сервер продолжает пинговаться, но остальные сервисы (ssh, http) более недоступны, пока его не перезагрузишь кнопкой Reset. Потом он снова работает максимум сутки-двое, по истичении которых - эта же картина. Попросил дата-центр повесить на сервер KVM-IP, чтобы посмотреть, что же там выводится на экран во время зависания (т.к. в логах о самом зависании и его причинах я ничего не нашёл), и то, что я увидел, выложено в прикреплённом файле. Как я понимаю, ошибка связана с записью на диск? Или с чем-то ещё? Устал уже ковыряться, переустановка Debian мне поможет? Или что можно сделать, чтобы избежать переустановки? На сервере 3 жёстких диска Seagate ST500DM002 (500 Гб SATA-3), 2 из них в fake-SATA-RAID-1 массиве, оставшийся 1 для бекапов работает не в массиве.

[qupl]

Я бы посмотрел в сторону управления питанием (засыпания системы в целом или остановки жестких дисков).

[yura3d]

Я бы посмотрел в сторону управления питанием (засыпания системы в целом или остановки жестких дисков).

Какие существуют для этого утилиты? В Гугле ничего интересного не нашёл. В BIOS'е ничего не менял, с этими же настройками сервер ранее работал безо всяких проблем.

[easy]

Или с чем-то ещё?

Может, китайцы брутфорсят? Как там с размерами secure логов?

Код Выделить Развернуть

ls -lS /var/log | head

[yura3d]

Может, китайцы брутфорсят?

Брутфорсили на прошлой неделе, вроде бы решилось дропом Китая и прочих подобных стран на уровне iptables + geoip (в самом дата-центре, как оказалось, нет никакого оборудования для защиты от DDoS, брутфорса, флуда и иже с ним, поэтому пришлось дропнуть на уровне сервера). До этого, например, в логах Apache было много срабатываний Suhosin patch при попытке доступа китайцев к phpMyAdmin. Сейчас вроде бы тихо.

Как там с размерами secure логов?

Код Выделить Развернуть

root@server:~# ls -lS /var/log | head
итого 4304
-rw-r----- 1 root        adm  439323 Фев 10 06:25 auth.log.3.gz
-rw-r----- 1 root        adm  417112 Фев 21 14:57 kern.log.2.gz
-rw-r----- 1 root        adm  397385 Фев 22 06:25 syslog.4.gz
-rw-r----- 1 root        adm  386737 Фев  3 06:25 auth.log.4.gz
-rw-r----- 1 root        adm  373284 Фев 22 06:25 messages.2.gz
-rw-r----- 1 root        adm  331329 Фев 22 06:25 auth.log.2.gz
-rw-rw-r-- 1 root        utmp 310656 Фев 25 15:13 wtmp
-rw-rw-r-- 1 root        utmp 292292 Фев 25 15:13 lastlog
-rw-rw-r-- 1 root        utmp 236928 Фев  1 02:30 wtmp.1
Не понимаю, от чего он ещё может валиться в спящий режим? Возможно, это делает не ОС, а материнская плата (BIOS)? Уже не знаю в какую сторону копать, раньше дело имел только с VDS

[qupl]

Мое первоначальное предположение про спячку неверное. Гугление говорит, что подобные ошибки встречаются при работе с программным raid-массивом либо аппаратными пролемами с жестким диском. Там упоминаются , в основном, старые ядра. Здесь, например, пишут про баг raid и ext4, даже предлагают костыль в опциях монтирования. Посмотрите может быть оно.

[ferum]

Мое первоначальное предположение про спячку неверное. Гугление говорит, что подобные ошибки встречаются при работе с программным raid-массивом либо аппаратными пролемами с жестким диском. Там упоминаются , в основном, старые ядра. Здесь, например, пишут про баг raid и ext4, даже предлагают костыль в опциях монтирования. Посмотрите может быть оно.

Почему нет? Если возникают проблемы с блоком питания то очень даже может быть. Проверять надо однозначно что бы бесполезной работой не заниматься.

[yura3d]

Гугление говорит, что подобные ошибки встречаются при работе с программным raid-массивом либо аппаратными пролемами с жестким диском. Там упоминаются , в основном, старые ядра.

У меня версия ядра 2.6.32-5-amd64, оно слишком старое? Там, как я почитал, и на 2.6.35 проблемы были замечены. Новое ядро в стабильных репах для squeeze уже видимо не появится, в свете скорого выхода wheezy stable ? Хотя я бы наверное и так не рискнул его обновлять, до Debian как-то часто приходилось иметь дело с Ubuntu, так там каждое обновление ядра приводило к большим проблемам, вплоть до неразрешимых..

В статье по ссылке выше (о проблеме софтового RAID при совместной работе с ext4) сказано следующее:

Just to follow up on this in case someone lands here from a search and doesn't want to dig through the even longer linked thread on the raid mailing list:

The problem turned out to be the combination of RAID and the barrier option on ext4. It seems to cause some kind of race condition during heavy writing scenarios. I've been mounting that filesystem with "-o barrier=0" for months with no further problems. The consensus seems to be that barriers are a nice thing to have but not critical - they were only added relatively recently and aren't even available with all hardware. So I feel relatively safe about avoiding it at least until the bug is fixed.

Подскажите, пожалуйста, как эту опцию "-o barrier=0" правильно прописать в /etc/fstab. У меня, в отличие от ситуации в статье, на этом самом RAID также и ОС установлена, можно ли эту опцию использовать при монтировании корня? Заранее благодарю!

[qupl]

Почему нет? Если возникают проблемы с блоком питания то очень даже может быть. Проверять надо однозначно что бы бесполезной работой не заниматься.

Я имею ввиду программную спячку - она здесь не при делах.

Подскажите, пожалуйста, как эту опцию "-o barrier=0" правильно прописать в /etc/fstab. У меня, в отличие от ситуации в статье, на этом самом RAID также и ОС установлена, можно ли эту опцию использовать при монтировании корня? Заранее благодарю!

Код (например, UUID и другие параметры монтирования оставьте свои) Выделить Развернуть

UUID=7ac33bb3-2506-40ff-b9ac-ee6799e7f261 /               ext4    errors=remount-ro,nobarrier 0       1


[yura3d]

UUID=7ac33bb3-2506-40ff-b9ac-ee6799e7f261 /               ext4    errors=remount-ro,nobarrier 0       1

Т.е. прописывать надо именно nobarrier вместо barrier=0 ? Прошу прощения за некоторую дотошность, просто боюсь, чтобы после перезагрузки всё вновь запустилось

[qupl]

Т.е. прописывать надо именно nobarrier вместо barrier=0 ? Прошу прощения за некоторую дотошность, просто боюсь, чтобы после перезагрузки всё вновь запустилось

Это эквивалентные записи. Прочтите man mount , чтобы не сомневаться.

[rayanAyar]

В smart-е ничего нет?

[yura3d]

Это эквивалентные записи. Прочтите man mount , чтобы не сомневаться.

Спасибо, прописал nobarrier в /etc/fstab для всех ext4-разделов и перезагрузил сервер. Пока что всё работает

В smart-е ничего нет?

Хм, даже не знаю, на что тут обратить внимание. Вот вывод smartctl -a /dev/sda целиком для одного из 2-х дисков RAID-массива, у второго данные приблизительно такие же:

Код Выделить Развернуть

smartctl 5.40 2010-07-12 r3124 [x86_64-unknown-linux-gnu] (local build)
Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net

=== START OF INFORMATION SECTION ===
Device Model:     ST500DM002-1BD142
Serial Number:    Z3T361DA
Firmware Version: KC45
User Capacity:    500 107 862 016 bytes
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   8
ATA Standard is:  ATA-8-ACS revision 4
Local Time is:    Wed Feb 27 16:20:08 2013 FET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status:  (0x82) Offline data collection activity
                                        was completed without error.
                                        Auto Offline Data Collection: Enabled.
Self-test execution status:      (   0) The previous self-test routine completed
                                        without error or no self-test has ever
                                        been run.
Total time to complete Offline
data collection:                 ( 600) seconds.
Offline data collection
capabilities:                    (0x7b) SMART execute Offline immediate.
                                        Auto Offline data collection on/off support.
                                        Suspend Offline collection upon new
                                        command.
                                        Offline surface scan supported.
                                        Self-test supported.
                                        Conveyance Self-test supported.
                                        Selective Self-test supported.
SMART capabilities:            (0x0003) Saves SMART data before entering
                                        power-saving mode.
                                        Supports SMART auto save timer.
Error logging capability:        (0x01) Error logging supported.
                                        General Purpose Logging supported.
Short self-test routine
recommended polling time:        (   1) minutes.
Extended self-test routine
recommended polling time:        (  81) minutes.
Conveyance self-test routine
recommended polling time:        (   2) minutes.
SCT capabilities:              (0x303f) SCT Status supported.
                                        SCT Error Recovery Control supported.
                                        SCT Feature Control supported.
                                        SCT Data Table supported.

SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   117   099   006    Pre-fail  Always       -       118588664
  3 Spin_Up_Time            0x0003   100   100   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   100   100   020    Old_age   Always       -       43
  5 Reallocated_Sector_Ct   0x0033   100   100   036    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000f   075   060   030    Pre-fail  Always       -       4328200277
  9 Power_On_Hours          0x0032   099   099   000    Old_age   Always       -       1583
10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
12 Power_Cycle_Count       0x0032   100   100   020    Old_age   Always       -       42
183 Runtime_Bad_Block       0x0032   100   100   000    Old_age   Always       -       0
184 End-to-End_Error        0x0032   100   100   099    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   100   100   000    Old_age   Always       -       0
188 Command_Timeout         0x0032   100   099   000    Old_age   Always       -       1
189 High_Fly_Writes         0x003a   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0022   071   062   045    Old_age   Always       -       29 (Lifetime Min/Max 15/31)
194 Temperature_Celsius     0x0022   029   040   000    Old_age   Always       -       29 (0 9 0 0)
195 Hardware_ECC_Recovered  0x001a   052   033   000    Old_age   Always       -       118588664
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0
240 Head_Flying_Hours       0x0000   100   253   000    Old_age   Offline      -       35648228558383
241 Total_LBAs_Written      0x0000   100   253   000    Old_age   Offline      -       4255609561
242 Total_LBAs_Read         0x0000   100   253   000    Old_age   Offline      -       3575324549

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
No self-tests have been logged.  [To run self-tests, use: smartctl -t]


SMART Selective self-test log data structure revision number 1
SPAN  MIN_LBA  MAX_LBA  CURRENT_TEST_STATUS
    1        0        0  Not_testing
    2        0        0  Not_testing
    3        0        0  Not_testing
    4        0        0  Not_testing
    5        0        0  Not_testing
Selective self-test flags (0x0):
  After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.

Судя по статье из Википедии, бояться больших значений Raw_Read_Error_Rate на жёстких дисках Seagate не стоит. Бэдов Reallocated_Sector_Ct нет ни на одном из дисков. Странно, smartctl выводит не все из параметров, может к отдельным из них по какой-то причине нет доступа?

[ihammers]

Я бы обратил внимание на следующие параметры:

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   117   099   006    Pre-fail  Always       -       118588664
...
  7 Seek_Error_Rate         0x000f   075   060   030    Pre-fail  Always       -       4328200277
  9 Power_On_Hours          0x0032   099   099   000    Old_age   Always       -       1583
...
195 Hardware_ECC_Recovered  0x001a   052   033   000    Old_age   Always       -       118588664
...
240 Head_Flying_Hours       0x0000   100   253   000    Old_age   Offline      -       35648228558383

1. хоть и в вики написано, что для этих фирм значения нормальны, но параметр который перевалил за 100 миллионов настораживает.
7. а этот параметр вообще перевалил за 4 миллиарда, параметр, по вики связан с позиционированием магнитных головок, что как видно с механикой не всё хорошо (моё мнение).
9. если параметр в часах, то 65 дней работы и такие большие значения, по мне так очень плохо, а если это в днях, то 4.4 года приличный срок для винта.
195. число коррекций ошибок тоже большое.
240. как по мне так странное число...

PS: на рабочей машине, которая мне досталась, после n-цати людей у Seagate ST3250310AS параметр Raw_Read_Error_Rate чуть меньше вашего, а Power_On_Hours -- 26741, не думаю что они изменили выводимые данные, то есть это у нас в часах.
PS:: если винты старые, то я бы посоветовал подыскать им замену, на всякий случай, положить и если что использовать.
PS::: а перед выводом команды smartctl -a делали проверку винта (short, long)?

[yura3d]

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

Винты новые, приобретались буквально 2 месяца назад в декабре, значение 9 Power_On_Hours в часах (1583 часов = 65 дней) верное. Поэтому даже и не знаю что сказать по поводу устрашающих значений других параметров

PS::: а перед выводом команды smartctl -a делали проверку винта (short, long)?

Можно, пожалуйста, с этого момента поподробнее? Как запустить такую проверку?
Сообщение объединено: 01 марта 2013, 15:30:18
Сегодня зависание повторилось, вот что обнаружил в /var/log/syslog:

Код Выделить Развернуть

Mar  1 12:17:25 vodila kernel: [162235.536205] BUG: unable to handle kernel paging request at ffff98000fa27230
Mar  1 12:17:25 vodila kernel: [162235.536241] IP: [<ffffffff8103aa48>] __wake_up_common+0x26/0x72
Mar  1 12:17:25 vodila kernel: [162235.536265] PGD 0
Mar  1 12:17:25 vodila kernel: [162235.536280] Oops: 0000 [#1] SMP
Mar  1 12:17:25 vodila kernel: [162235.536297] last sysfs file: /sys/devices/virtual/block/dm-2/dm/name
Mar  1 12:17:25 vodila kernel: [162235.536318] CPU 3
Mar  1 12:17:25 vodila kernel: [162235.536332] Modules linked in: btrfs zlib_deflate crc32c libcrc32c ufs qnx4 hfsplus hfs minix ntfs vfat msdos fat jfs xfs exportfs reiserfs ext3 jbd ext2 fuse lm78 hwmon_vid i2c_core loop snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_timer snd soundcore video shpchp pci_hotplug snd_page_alloc output psmouse parport_pc parport evdev pcspkr serio_raw processor button ext4 mbcache jbd2 crc16 dm_mirror dm_region_hash dm_log dm_mod sd_mod crc_t10dif ehci_hcd ahci xhci libata scsi_mod fan r8168 usbcore nls_base thermal thermal_sys [last unloaded: scsi_wait_scan]
Mar  1 12:17:25 vodila kernel: [162235.536536] Pid: 22228, comm: apache2 Not tainted 2.6.32-5-amd64 #1 MS-7758
Mar  1 12:17:25 vodila kernel: [162235.536557] RIP: 0010:[<ffffffff8103aa48>]  [<ffffffff8103aa48>] __wake_up_common+0x26/0x72
Mar  1 12:17:25 vodila kernel: [162235.536593] RSP: 0000:ffff8800bd841d38  EFLAGS: 00010092
Mar  1 12:17:25 vodila kernel: [162235.536612] RAX: ffff98000fa27230 RBX: ffff88000fa27228 RCX: 0000000000000000
Mar  1 12:17:25 vodila kernel: [162235.536644] RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffff88000fa27228
Mar  1 12:17:25 vodila kernel: [162235.536676] RBP: 0000000000000001 R08: ffff98000fa27218 R09: 0000000000000000
Mar  1 12:17:25 vodila kernel: [162235.536708] R10: ffff8800a971ec38 R11: 0000000000000008 R12: ffff8800bd841da8
Mar  1 12:17:25 vodila kernel: [162235.536740] R13: ffff88000fa27230 R14: ffff8800bd841da8 R15: 0000000000000000
Mar  1 12:17:25 vodila kernel: [162235.536772] FS:  00007fd12b85c740(0000) GS:ffff88000fd80000(0000) knlGS:0000000000000000
Mar  1 12:17:25 vodila kernel: [162235.536806] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
Mar  1 12:17:25 vodila kernel: [162235.536826] CR2: ffff98000fa27230 CR3: 000000009b18d000 CR4: 00000000000406e0
Mar  1 12:17:25 vodila kernel: [162235.536858] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Mar  1 12:17:25 vodila kernel: [162235.536890] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Mar  1 12:17:25 vodila kernel: [162235.536922] Process apache2 (pid: 22228, threadinfo ffff8800bd840000, task ffff88041a461530)
Mar  1 12:17:25 vodila kernel: [162235.536955] Stack:
Mar  1 12:17:25 vodila kernel: [162235.53696Mar  1 13:06:26 vodila kernel: imklog 4.6.4, log source = /proc/kmsg started.

На этот раз присутствуют указания на проблемный процесс apache2, первый раз такое вижу. Из последней строки видно, что лог не дописался в файл, и новая запись (после перезагрузки сервера) "легла" поверх старой