Сообщение disk monitor got sigalrm в системном журнале означает, что процесс мониторинга диска получил сигнал SIGALRM — таймерный сигнал, который в Unix-подобных системах отправляется по истечении интервала, заданного вызовом alarm(). Чаще всего подобные строки встречаются в выводе syslog или journalctl рядом с записями служб вроде smartd, watchdog или собственных скриптов мониторинга, и сами по себе они не всегда указывают на сбой — иногда это штатная часть цикла опроса дисков.
Проблема начинается тогда, когда запись появляется слишком часто, сопровождается перезапуском демона, ростом load average или ошибками ввода-вывода. В этой статье разберём, что стоит за сигналом, как отличить нормальное поведение от симптома неисправности и какие шаги диагностики безопасны на рабочей системе.
Что такое SIGALRM и почему его получает монитор диска
SIGALRM — один из стандартных сигналов POSIX. Программа вызывает функцию alarm(n), и через n секунд ядро доставляет процессу этот сигнал. Разработчики демонов мониторинга используют его как будильник: чтобы периодически просыпаться, опрашивать состояние дисков и снова засыпать.
Таким образом, строка got sigalrm в логе часто означает лишь то, что сработал внутренний таймер процесса. Если демон написан с подробным (debug) уровнем логирования, он фиксирует каждое такое событие. Это не ошибка, а трассировка.
Другое дело — когда сигнал приходит неожиданно или обработчик завершается с ошибкой. Тогда рядом в журнале появляются записи о таймаутах, невозможности прочитать данные S.M.A.R.T. или перезапуске службы. Именно такая комбинация требует внимания администратора.
Где искать эти записи в системе
Первый шаг — понять, какой именно процесс пишет сообщение. В современных дистрибутивах с systemd журнал смотрят командой:
journalctl -u smartd --since "today"Если служба другая, подставьте её имя или выполните поиск по всему журналу:
journalctl | grep -i sigalrmВ системах с классическим syslog записи обычно находятся в /var/log/syslog или /var/log/messages. Обратите внимание на столбец с именем процесса и PID — это подскажет, кто именно получает сигнал.
- 🔍 Имя процесса рядом с сообщением — ключ к источнику проблемы.
- 🕐 Частота появления записей: раз в интервал опроса — норма, несколько раз в секунду — аномалия.
- 📄 Соседние строки лога: ошибки чтения, таймауты, перезапуски.
- ⚙️ Уровень логирования демона — возможно, включён режим отладки.
Возможные причины аномального поведения
Если записи появляются подозрительно часто или сопровождаются сбоями, возможные причины стоит искать в нескольких направлениях. Ни одну из них нельзя считать установленным фактом без проверки — это гипотезы, которые нужно подтверждать логами и тестами.
- 💾 Диск не отвечает на запросы вовремя — например, из-за проблем с кабелем, контроллером или деградации самого накопителя.
- ⚡ Нестабильное питание или «засыпание» диска (spindown), из-за которого опрос занимает дольше отведённого интервала.
- 🐞 Ошибка или несовместимость версии демона мониторинга с конкретной моделью накопителя.
- 🔧 Слишком агрессивный интервал опроса в конфигурации — таймер срабатывает до завершения предыдущего цикла.
- 🧩 Сторонние скрипты или watchdog, которые сами посылают сигналы процессу.
⚠️ Внимание: прежде чем менять конфигурацию служб или отключать мониторинг, убедитесь, что проблема не в самом накопителе. Отключение мониторинга на деградирующем диске лишит вас раннего предупреждения о сбое.
Диагностика состояния диска
Параллельно с анализом логов стоит проверить здоровье накопителя. Для этого используется утилита smartctl из пакета smartmontools — если она установлена в вашей системе:
smartctl -a /dev/sdaВывод покажет атрибуты S.M.A.R.T., журнал ошибок и результат самодиагностики. Особое внимание обратите на пересчитанные (reallocated) сектора, количество ошибок чтения и температуру. Точная интерпретация атрибутов зависит от производителя диска, поэтому сверяйтесь с документацией вендора.
Дополнительно проверьте системный журнал на предмет ошибок контроллера — сообщения ядра вида ata1: link is slow to respond или сбросы шины SATA указывают уже на аппаратный уровень проблемы.
☑️ Базовая диагностика при «disk monitor got sigalrm»
Настройка демона мониторинга
Если диагностика показала, что диски здоровы, а сообщения вызваны конфигурацией, можно скорректировать параметры службы. Для smartd настройки хранятся в файле /etc/smartd.conf (путь может отличаться в зависимости от дистрибутива — проверьте документацию вашей системы).
Типичные меры: увеличить интервал опроса, отключить проверки для дисков, которые корректно не поддерживают определённые команды, или понизить уровень детализации логов, если включён отладочный режим. После правок службу нужно перезапустить:
systemctl restart smartdВносите изменения по одному и наблюдайте за журналом после каждого шага — так вы точно поймёте, какое действие устранило симптом. Одновременное изменение нескольких параметров затрудняет диагностику, если проблема вернётся.
Когда проблема аппаратная
Признаки, указывающие на железо, а не на конфигурацию: ошибки чтения в выводе smartctl, сообщения ядра о сбросе шины, зависания операций ввода-вывода, рост времени отклика диска. В такой ситуации сигнал SIGALRM — лишь следствие: демон не дожидается ответа накопителя в отведённое время.
Порядок действий здесь обратимый и безопасный: сначала сделайте резервную копию важных данных, затем проверьте кабели и разъёмы (при выключенном питании), попробуйте другой порт контроллера. Если ошибки следуют за диском независимо от порта и кабеля — вероятнее всего, проблема в самом накопителе.
⚠️ Внимание: при подтверждённых ошибках чтения или растущем числе переназначенных секторов не откладывайте резервное копирование. Дальнейшая эксплуатация такого диска под нагрузкой может привести к внезапной потере данных.
Почему нельзя просто подавить сообщение в логе
Фильтрация записей в rsyslog или journald скроет симптом, но не устранит причину. Если за частыми срабатываниями таймера стоит медленно умирающий диск или конфликт демонов, вы потеряете единственный ранний индикатор. Сначала диагностика — потом косметика логов.
Профилактика повторения проблемы
После устранения причины имеет смысл навести порядок в мониторинге. Убедитесь, что уведомления о критических ошибках дисков реально доставляются — например, настроена отправка почты через smartd, если эта функция предусмотрена вашей конфигурацией. Проверьте это тестовым событием, а не ждите реального сбоя.
Также полезно периодически просматривать журнал на предмет новых паттернов: появление записей, которых раньше не было, — самый ранний сигнал изменений в системе. Регулярный обзор логов занимает минуты, но экономит часы восстановления.
Часто задаваемые вопросы
Опасна ли сама по себе запись «disk monitor got sigalrm»?
Как правило, нет. Это фиксация штатного таймерного сигнала, который демон мониторинга использует для периодического опроса дисков. Беспокойство оправдано, только если запись появляется аномально часто или соседствует с ошибками ввода-вывода и перезапусками службы.
Как узнать, какой процесс получает SIGALRM?
Откройте журнал командой journalctl | grep -i sigalrm и посмотрите имя процесса и PID в строке сообщения. Затем изучите логи именно этой службы через journalctl -u имя_службы.
Можно ли просто отключить мониторинг дисков?
Технически можно, но делать это стоит только после проверки состояния накопителей. Мониторинг — это механизм раннего предупреждения о деградации диска, и его отключение лишает вас возможности вовремя заменить сбоящий накопитель.
Что делать, если smartctl показывает ошибки диска?
Сначала сделайте резервную копию важных данных. Затем проверьте кабели и порт контроллера, чтобы исключить проблемы подключения. Если ошибки сохраняются независимо от подключения, накопитель, вероятно, деградирует, и его стоит планово заменить.
Может ли спящий режим диска вызывать эти сообщения?
Да, это одна из возможных причин. Если диск «засыпает» для экономии энергии, а демон пытается его опросить, ответ занимает дольше обычного, что может отражаться в логах. Настройки пропуска спящих дисков описаны в документации к вашему демону мониторинга.