Home » Linux » A start job is running for File System Check

A start job is running for File System Check

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

Онлайн-курс "Базы данных" – для разработчиков, администраторов СУБД и всех, кто стремится повысить профессиональный уровень, научиться проектировать базы данных и создавать оптимальную структуру их хранения (PostgreSQL, MySQL, Redis, MongoDB, Cassandra и т. д.) Подробности по .

Force fsck on reboot

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

A start job is running for File System Check

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

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

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

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

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

Centos 8 rescue boot

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

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

systemd-fsck

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

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

systemd-fsck check forced

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

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

filesystem    dir    type    options    dump    pass

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

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

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

Заключение

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

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

# shutdown -rf now

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

Онлайн курс "Базы данных"

Онлайн-курс "Базы данных" – для разработчиков, администраторов СУБД и всех, кто хочет эффективно работать с любой базой данных (как реляционной, так и нереляционной) с помощью языка структурированных запросов SQL. Курс не для новичков – нужно пройти вступительный тест. Выпускники курса смогут:
  • проектировать базы данных и создавать оптимальную структуру их хранения;
  • различать основные СУБД, которые могут пригодиться разработчику (PostgreSQL, MySQL, Redis, MongoDB, Cassandra и т. д.);
  • освоить синтаксис и особенности работы SQL, DDL, DML;
  • оптимизировать медленные запросы и разбираться с некорректными SQL-запросами;
  • уверенно работать с индексами, оптимизировать, профилировать и обновлять базы данных.
Проверьте себя на вступительном тесте и смотрите программу детальнее по .

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

Анонсы всех статей, плюс много другой полезной и интересной информации, которая не попадает на сайт.

Автор Zerox

Владимир, системный администратор, автор сайта. Люблю настраивать сервера, изучать что-то новое, делиться знаниями, писать интересные и полезные статьи. Открыт к диалогу и сотрудничеству. Если вам интересно узнать обо мне побольше, то можете послушать интервью. Запись на моем канале - https://t.me/srv_admin/425 или на сайте в контактах.

8 комментариев

  1. Дядя Вася

    во многих экзаменах по линуксу есть вопросы об автоматической проверке файловой системе. статья говорит о поверхностных знаниях автора в данном вопросе. подтягивайте матчасть, успехов вам.

  2. Вы можете отключить\изменять параметры проверок ФС с помощью tune2fs:

    -c max-mount-counts
    Adjust the number of mounts after which the filesystem will be checked by e2fsck(8).
    If max-mount-counts is 0 or -1, the number of times the filesystem is mounted will be
    disregarded by e2fsck(8) and the kernel.

    -C mount-count
    Set the number of times the filesystem has been mounted. If set to a greater value
    than the max-mount-counts parameter set by the -c option, e2fsck(8) will check the
    filesystem at the next reboot.

    -i interval-between-checks[d|m|w]
    Adjust the maximal time between two filesystem checks. No postfix or d result in days,
    m in months, and w in weeks. A value of zero will disable the time-dependent checking.

    It is strongly recommended that either -c (mount-count-dependent) or -i (time-depen-
    dent) checking be enabled to force periodic full e2fsck(8) checking of the filesystem.
    Failure to do so may lead to filesystem corruption (due to bad disks, cables, memory,
    or kernel bugs) going unnoticed, ultimately resulting in data loss or corruption.

  3. Спасибо, давно искал как разобраться с данной проблемой :)

  4. Руслан

    А что за параметр в fstab если поставить 1 на дамп ? Я специально несколько раз ставил на ф.с. xfs в fstab dump =1 так ничего и не происходило во время перезагрузки, загрузки, никаких дампов не делает и в логах не слова

    Может кто сталкивался с дампами ? Куда он их складывает

    • В документации четко прописано, что это за параметр и зачем он нужен. Но лично я никогда не тестировал его работу. Чтобы что-то произошло, в системе как минимум должна быть установлена утилита dump.

      • Руслан

        В документации все запутано, остаётся куча вопросов, работает ли в xfs или только в ext, для лент это или нет, куда скоадирует ? По факту я тестил, не работат ! , нужен ли дамп или xfs_dump ? В интернете, так вообще никто ею не пользуется, что бы понять как это работает...

  5. Осталось в Zabbix сделать шаблон который пройдет по всем сервакам и подскажет от какого дальше ждать привета.

    • Можно и вручную проверить перед перезагрузкой. Обычно это не такая частая процедура. Тут просто совпало так, что и размер большой, и параметр не выставлен в 0 в fstab. Так то я обычно 0 0 ставлю и все.

Добавить комментарий

Ваш адрес email не будет опубликован.

Нажимая кнопку "Отправить комментарий" Я даю согласие на обработку персональных данных.