A start job is running for File System Check

Столкнулся на днях с очень неприятной ситуацией, сопровождающейся тем, что сервер долго не мог запуститься. Причиной этому была плановая проверка диска на ошибки. Сам диск был на 3 Тб, поэтому проверка сильно затянулась. В итоге, банальная установка обновлений и reboot чуть превратились в серьезную проблему.

Force fsck on reboot

Удивительно, но на за все время своей работы системным администратором Linux, с подобной проблемой я столкнулся впервые. Как говорится, ничто не предвещало беды. Выбрал наиболее подходящее время для обновления системы и сделал его. После этого решил перезагрузить сервер. Операция была запланированная и до этого я уже обновил с десяток серверов. Но с этим последним что-то пошло не так. Долго не возвращается в мониторинг. Решил сходить на гипервизор и посмотреть, что с ним. А там такая картинка.

A start job is running for File System Check on /dev/vgmail/mail

Идет проверка раздела на ошибки. При чем этот lvm раздел размером в 3Tb, на нем хранится почтовый архив. Нет никакой индикации и не понятно, с чем вообще все это связано и сколько времени продлится. Сервер в работе, подключается куча людей. Я вижу, что операция вроде как плановая, так как никаких ошибок нет. Но то, что сервер не работает, уже ошибка. Самое главное, не понятно, сколько эта проверка может длиться. И еще всегда остается шанс, что это внештатная ситуация и с разделом какие-то проблемы. Это самый плохой расклад.

Я терпеливо подождал где-то час и не выдержал. В первую очередь хотел понять, происходил ли вообще что-то с диском. Пошел на гипервизор и проверил. Реально идет активное чтение с диска. Записи нет. Из этого сделал вывод, что можно безопасно сбросить виртуалку. К слову, весь тот час, что я ждал, прогуглил весь буржунет, чтобы понять, как принудительно прервать эту проверку. Перепробовал все, что только можно. Не помогло ничего. Прервать или отложить проверку не смог.

Параллельно сходил и проверил бэкап. Он был, свежий, все в порядке. Но сколько времени займет восстановление, если забирать эти данные по сети? Я так прикинул, никак не меньше суток, скорее ближе к двум. Надо было бы ехать и забирать локально. Сначала в один цод, потом во второй. Везде надо договариваться о приезде, оформлять пропуск и т.д. Сидеть ждать, пока локально скопируется файлы. Как-то еще внешний диск надо подключить и найти подходящего объема. В общем, та еще проблема. Одно наличие актуального бэкапа вообще не решает проблему восстановления данных.

В итоге сбросил виртуалку и при загрузке выбрал режим Rescue.

Я рассчитывал, что в этом режиме проверка диска не будет запускаться. По факту ошибся, проверка тоже запустилась, но в этот раз периодически в строке проскакивала индикация выполнения и было видно, что она продолжается. Так же, по изменению статуса, я прикинул, что проверка будет длиться около двух часов. Я посчитал, что для меня это время приемлемо в данной ситуации и решил больше не дергать виртуалку, чтобы не сделать хуже. Дождался окончания процесса.

В итоге, все завершилось и операционная система штатно загрузилась. В логах увидел подробности:

systemd-fsck: /dev/mapper/vgmail-mail has gone 357 days without beign checked, check forced.

Система в системе в виде systemd решила, что диск давно не проверяли на ошибки, поэтому принудительно инициировала этот процесс, который длился в итоге 1,5 часа. Первый раз немного не дождался окончания.

Как отключить fsck при загрузки системы

По идее, чтобы подобные проверки не запускались автоматически, достаточно в fstab, в последнем столбце написать 0. Напомню, что это за параметр. Формат файла fstab следующий:

filesystem    dir    type    options    dump    pass

Последняя строка как раз для fsck, может принимать следующие значения:

• 0 - проверка отключена полностью. То, что надо было указать мне в самом начале.
• 1 - наивысший приоритет проверки.
• 2 - менее высокий приоритет очередности проверки.

У меня стояла цифра 2. Я не знаю, чем руководствовался, когда настраивал fstab. Скорее всего на автомате указал или скопировал. Не подумал о последствиях. Есть только один момент, который меня беспокоит. Не факт, что systemd руководствуется этим параметром, а не каким-то своим. Она давно уже живет своей жизнью и требует отдельных настроек и внимания к себе. Нужно будет разобраться с этим моментом повнимательнее.

Заключение

Ранее неоднократно сталкивался с принудительной проверкой массива mdadm на ошибки. Это очень сильно нагружает диски и катастрофически снижает производительность системы. Всегда слежу за этим и отключаю проверку. Какая-то бестолковая затея инициировать подобные проверки автоматически, без согласования с администратором, либо ручным выбором условий запуска. Причем в разных дистрибутивах это может быть реализовано по-разному. Проверки надо делать при подозрении на ошибки, а не просто так, чтобы было.

Теперь вот буду отдельно и внимательно следить за fsck, чтобы спокойно перезагружаться. К слову, если хотите гарантированно перезагрузить систему, отключив проверку fsck, надо использовать флаг -f при перезагрузке.

# shutdown -rf now

На практике не проверял. Узнал об это уже по факту разбора данной ситуации.

Помогла статья? Подписывайся на telegram канал автора