Хакер, номер # 103, стор. 103-102-1
Огляд програм для моніторингу роботи заліза в Linux
Літо. На вулиці вже який день стоїть спека. Три вентилятора в системному блоці з великими труднощами справляються з охолодженням, хоча шумлять пристойно. Іноді створюється враження, що системний блок можна використовувати замість грубки. Як дізнатися, що відбувається всередині, чи не торкаючись пальцями до деталей включеного комп'ютера? Може, вже пора дати відпочити своєму залізному другу? Або поставити ще один кулер? У складі будь-якого дистрибутива Linux знайдеться кілька утиліт, які допоможуть отримати відповідь на ці та інші питання і розкажуть все про поточний стан заліза.
lm-sensors: стандарт де-факто
В ядрах 2.4 установка lm-sensors могла викликати легкий стрес, але з інтеграцією в ядро 2.6 компонентів, які здійснюють моніторинг, змусити її працювати вже не проблема. Інформацію про підтримку свого обладнання lm-sensors та ядром можна знайти на сторінці Devices and drivers (www.lm-sensors.org/wiki/Devices). Тут же уточнюємо, скільки разів lm-sensors рекомендується використовувати з встановленим в системі ядром. Хоча можна особливо і не вибирати, а ставити те, що пропонується в репозитарії. Так як утиліти діагностики частиною ядра не є, їх слід встановлювати окремо:
$ Sudo apt-get install lm-sensors sensord
Заодно встановимо і демон sensord, його завдання збирати інформацію в syslog. Крім того, в разі неприємностей він може видати попередження. Для початкового налаштування системи моніторингу слід використовувати утиліту sensors-detect:
Після запуску утиліти тобі буде влаштований справжній допит з пристрастю. Слід відповідати чесно, нічого не приховуючи :). У разі сумніву можна вирішувати всі тести. Утиліта пройдеться по всіх шинам і пристроїв, перебере всі скомпільовані модулі і вибере ті, від яких є хоч якийсь зиск. Якщо буде виведена хоча б пара. вважай, що тобі пощастило. А значить, моніторингу бути. Після закінчення утиліта запросить створити настройки відповідно до знайденим обладнанням: - і видасть рядок, яку необхідно вставити в файл / etc / modules. Вибравши на наступному кроці Yes, можна дозволити їй зробити це самостійно.
Раджу перевірити в /lib/modules/2.6.x/modules наявність всіх модулів, які порекомендував завантажити sensors-detect. Скрипт іноді біжить попереду паровоза або, навпаки, відстає, тому цілком можливо, що таких модулів в системі просто немає. Так, одного разу мені було запропоновано використовувати i2c-nforce2, але такий модуль в системі відсутній. Як варіант - можна спробувати завантажити модулі вручну за допомогою.
Для отримання інформації з сенсорів викликаємо утиліту sensors без параметрів (можна вже під звичайним користувачем):
Adapter: SMBus I801 adapter at c800
VoltA1_5: +1.49 V (min = +1.42 V, max = +1.58 V)
Volt1_5: +1.52 V (min = +1.45 V, max = +1.60 V)
Volt3_3: +3.23 V (min = +3.13 V, max = +3.47 V)
Volt5: +5.20 V (min = +4.74 V, max = +5.26 V)
Volt12: +12.01 V (min = +11.38 V, max = +12.62 V)
FanCPU: 3540 RPM (min = 4000 RPM)
TempCPU: + 28C (low = + 10C, high = + 55C)
TempMB1: + 31C (low = + 10C, high = + 55C)
TempMB2: + 34C (low = + 10C, high = + 55C)
vid: +1.525 V (VRM Version 9.1)
Параметри виведення на екран налаштовуються у файлі /etc/sensors.conf. Шукаємо рядок, що відповідає нашому чіпу (в нашому прикладі це lm85), і правимо при необхідності:
$ Sudo mcedit /etc/sensors.conf
chip "lm85c- *" "adm1027- *" "adt7463- *" "lm85- *" "lm85b- *"
label in0 "V1.5"
label in1 "VCore"
label temp1 "CPU Temp"
label temp2 "Board Temp"
label fan1 "CPU_Fan"
# Установка ліміту вольтажа
set in0_min 1.5 * 0.95
set fan1_min 4000
Хотілося б звернути увагу на утиліту KSensors (ksensors.sourceforge.net), яка є графічним інтерфейсом до sensors для середовища KDE. В Ubuntu вона встановлюється звичайним чином:
$ Sudo apt-get install ksensors
Тепер запускаємо її через меню або з командного рядка. Клацаємо по з'явився значку і вибираємо Configure. Потім переходимо по вкладках і включаємо прапорець Visible в тих параметрах, які хочемо бачити. Результат буде виведений на панелі завдань (якщо активований Dock) і в окремому вікні, яке відкривається подвійним клацанням по значку KSensors. Крім параметрів, контрольованих за допомогою утиліти lm-sensors, можна виводити стан пам'яті, swap і деяку іншу інформацію. Для кожного параметра можна виставити інтервал оновлення і реакцію системи при перевищенні заданого значення (виконати команду або програти звук). Щоб KSensor автоматично запускався при завантаженні системи, не забудь встановити Autostart KSensors on KDE startup у вкладці Global settings.
Налаштування демона sensord виробляються в файлі / etc / default / sensord.
$ Sudo mcedit / etc / default / sensord
# Інтервал для сканування на попередження (30s, 1m, 1h)
# Інтервал між вимірами для запису в журнал
# Чіп беремо з sensors.conf
# Інтервал, за замовчуванням 5 хвилин
У комплекті lm-sensors йде утиліта pwmconfig, яка перевіряє можливість зміни швидкості обертання кулерів. Якщо така функціональність є, для настройки швидкості обертання слід використовувати утиліту fancontrol. Конфігураційний файл для неї створюється за допомогою pwmconfig.
Утиліта (x) mbmon
$ Sudo apt-get install mbmon xmbmon
Тепер можна запускати без будь-яких налаштувань:
Temp. = 30.0, 24.0, 127.0; Rot. = 3308, 0, 6026
Vcore = 1.14, 1.52; Volt. = 3.28, 5.00, 11.49, -6.62, -1.83
Запустивши xmbmon, всю цю інформацію можна побачити у вікні програми.
Моніторинг жорсткого диска з hddtemp
Взагалі кажучи, процесор не найголовніша частина комп'ютера. Ось якщо полетить жорсткий диск, вважай, пропали фільми, курсових та дипломних і т.д. Тому гвинт вимагає особливої уваги. У Linux є ряд утиліт якраз для цього випадку. Почнемо з маленької за розміром, але дуже корисною утиліти hddtemp (www.guzu.net/linux/hddtemp.php). З її допомогою можна отримувати інформацію про температуру з IDE / SATA / SCSI-дисків, а також зчитувати S.M.A.R.T. інформацію. встановлюємо:
$ Sudo apt-get install hddtemp
Крім цього, рекомендується оновити і базу дисків, скачавши файл www.guzu.net/linux/hddtemp.db і помістивши його в / etc. Виклик дуже простий:
$ Sudo hddtemp / dev / sda
/ Dev / sda: ST3160811AS: немає датчика
Так, з баракудою не пощастило, подивимося, що скаже утиліта про другому диску:
$ Sudo hddtemp / dev / hdb
/ Dev / hdb: QUANTUM FIREBALLlct20: 31C or F
Результат: температура Файрбол. Як варіант - hddtemp можна запустити в тлі. Отримати інформацію в цьому випадку можливо в журналі syslog або підключившись по мережі:
$ Sudo hddtemp -d -q / dev / hdb
$ Telnet localhost 7634
Connected to localhost.
Escape character is '^]'.
| / Dev / hdb | QUANTUM FIREBALLlct20 30 | 32 | C | Connection closed by foreign host.
Результат: 32 градуси. Таким чином температура диска з'ясовується навіть без регістріраціі в системі.
комплект smartmontools
За допомогою набору утиліт smartmontools (smartmontools.sf.net) можна контролювати і управляти деякими параметрами жорсткого диска, використовуючи технологію S.M.A.R.T. Підтримуються диски з інтерфейсами ATA, SCSI і SATA. Для початку варто перевірити статус підключених пристроїв:
$ Sudo smartd -q onecheck
Opened configuration file /etc/smartd.conf
Drive: DEVICESCAN, implied '-a' Directive on line 22 of file /etc/smartd.conf
Configuration file /etc/smartd.conf was parsed, found DEVICESCAN, scanning devices
Device: / dev / hda, opened
Device: / dev / hda, packet devices [this device CD / DVD] not SMART capable
Unable to register ATA device / dev / hda at line 22 of file /etc/smartd.conf
Device: / dev / hdb, opened
Device: / dev / hdb, found in smartd database.
Device: / dev / hdb, is SMART capable. Adding to "monitor" list.
Device: / dev / sda, opened
Device: / dev / sda, IE (SMART) not enabled, skip device
Try 'smartctl -s on / dev / sda' to turn on SMART features
Unable to register SCSI device / dev / sda at line 22 of file /etc/smartd.conf
Monitoring 1 ATA and 0 SCSI devices
Останній рядок показує, що буде проводитися моніторинг тільки ATA-диска. На пристрої / dev / sda SMART не активований, при необхідності його можна включити за допомогою виклику. Пробуємо отримати інформацію про диск:
$ Sudo smartctl -i / dev / hdb
Model Family: QUANTUM FIREBALLlct20 series
Device Model: QUANTUM FIREBALLlct20 30
Firmware Version: APL.3900
User Capacity: 30.020.272.128 bytes
Device is: In smartctl database [for details use: -P show]
ATA Version is: 5
ATA Standard is: ATA / ATAPI-5 T13 1321D revision 1
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
Більш повну інформацію можна отримати, запустивши утиліту з прапором '-a'. Висновок займе пару екранів, в самому кінці буде виведена таблиця зі списком контрольованих параметрів. Особливу увагу слід звернути на поле WHEN_FAILED, в якому відобразиться приблизна дата, коли цей параметр досягне свого допустимої межі. Ці тести можна викликати і окремо. Причому є два варіанти: скорочений і повний. Вони ініціюються командами:
$ Sudo smartctl -t short / dev / hdb
$ Sudo smartctl -t long / dev / hdb
Скорочена перевірка триває 1-2 хвилини, повна може зайняти близько години. На роботу диска ці тести ніяк не впливають, тому їх можна спокійно запускати на працюючій системі. Помилка буде виведена в поле LBA_of_first_error. Колонка LifeTime покаже час, що минув з моменту включення диска до проведення перевірки. Офлайнові тести запускаються командою smartctl -t offline; їх призначення - оновлення показників стану диска, які не можуть бути оновлені під час звичайної роботи. Використовуючи smartctl -o on. можна дозволити дискам виробляти таку перевірку самостійно.
Моніторинг слід проводити постійно. Для цих цілей використовується демон smartd, який також входить до складу smartmontools. За замовчуванням він перевіряє всі диски кожні 30 хвилин, інформацію виводить за допомогою syslog. Демона можна навчити при виявленні проблем відсилати поштове повідомлення адміністратору або виконувати скрипт. Шаблон містить велику кількість прикладів. Кожен рядок файлу описує параметри одного з присутніх в системі дисків. наприклад:
$ Sudo mcedit /etc/smartd.conf
/ Dev / sda -S on -o on -a -I 194 -m [email protected]
/ Dev / hdb -S on -o on -a -I 194 -m [email protected]
Тут ми вказуємо диск, директивою -S on включаємо автоматичне збереження значень показників. -o on відповідає за проведення регулярного офлайнового тестування. За допомогою -I 194 ігноруємо значення показника з ID # 194, що відповідає за контроль температури, і в кінці вказуємо email для відправки повідомлень. Перевірити відсилання повідомлень можна командою smartd -M test. Тепер запускаємо демон:
$ Sudo /etc/init.d/smartd start
Ось, загалом-то, і все, про що мені хотілося сьогодні розповісти. До речі, користувачі FreeBSD теж не обділені можливостями спостереження за здоров'ям своєї системи. Все необхідне можна знайти в дереві / usr / ports / sysutils колекції портів. З графічних утиліт, що не потрапили в огляд, варто відзначити gkrellm (www.gkrellm.net) і conky (conky.sf.net), з якими, я сподіваюся, ти розберешся вже сам.
Файлова система / proc
Деяку інформацію можна отримати, звернувшись безпосередньо до файлової системи / proc. Для прикладу перевіримо, чи включений кулер на процесорі:
$ Sudo cat / proc / acpi / fan / FAN / state
$ Sudo cat / proc / acpi / thermal_zone / THRM / temperature
temperature: 23 C
У trip_points можна вважати або задати політику управління охолодженням системи:
$ Sudo cat / proc / acpi / thermal_zone / THRM / trip_points
critical (S5): 65 C
passive: 63 C: tc1 = 4 tc2 = 3 tsp = 60 devices = 0xdf852338
active [0]: 63 C: devices = 0xdf85ff90
Можливі три варіанти політики: critical (критична температура, після якої можливий автоматичний перехід в сплячий режим), passive (зменшення частоти процесора) і active (активний режим роботи кулера). Причому active може мати кілька ступенів: від 0 до 9. Команда на зміну цих параметрів виглядає так:
$ Echo -n "critical: hot: passive: active0. ActiveX"> trip_points
$ Echo "105: 100: 100: 78: 70: 60: 50"> / proc / acpi / thermal_zone / TZ0 / trip_points
$ Sudo cat / proc / acpi / thermal_zone / THRM / cooling_mode
cooling mode: active
Встановлювати пасивний режим можливо не на всіх пристроях, хоча сучасні ноутбуки його зазвичай підтримують. Частота опитування сенсорів вказується в polling_frequency:
$ Sudo cat / proc / acpi / thermal_zone / THRM / polling_frequency
Це означає, що в разі змін сам пристрій здатне генерувати асинхронні переривання, тому спостерігати за ним немає сенсу. Більш детальну інформацію про thermal_zone можна знайти на сайті acpi.sourceforge.net/documentation/thermal.html.
підготовка дистрибутива
Для того щоб більшість описаних утиліт запрацювало, необхідно мати підтримку I2C і Hardware Monitoring в ядрі. Тобто як мінімум за все, що видають команди і. Тому якщо висновок мовчить як риба об лід, можеш сміливо приступати до перезібравши ядра. У Hardware Monitoring не забуваємо включити підтримку своєї материнської плати. Якщо сумніваєшся, то просто збери все у вигляді модулів.
$ Sudo make mеnuconfig
Включаємо підтримку ACPI:
Power management options (ACPI, APM) - ACPI (Advanced Configuration and Power Interface) Support
Не забуваємо стандарт управління сенсорами IPMI:
Device Drivers - Character devices - IPMI
Обов'язково включаємо підтримку сенсорів в ядрі:
Device Drivers - I2C support
Вибираємо алгоритми, використовувані в чіпах:
Device Drivers - I2C support ---> I2C Algorithms
У наступних пунктах вибираємо встановлений чіпсет:
Device Drivers - I2C support - I2C Hardware Bus support
Device Drivers - I2C support - Miscellaneous I2C Chip support
І, нарешті, вибираємо драйвери сенсорів:
Device Drivers - Hardware Monitoring support
Починаючи з версії ядра 2.6.19, з'явився новий драйвер моніторингу k8temp. який підтримує всі останні моделі AMD K8. У відповідних системах цей драйвер завантажується автоматично. Відзначено його несумісність із старими версіями lm-sensors. Тому обов'язково обнови утиліту або занеси k8temp в чорний список, інакше General parse error тобі забезпечена.