Пошкоджена файлова система — це той «сюрприз», який ніхто не хоче бачити на екрані під час завантаження. Добра новина: Linux вже уміє автоматично запускати fsck на старті, а ми додамо зверху розумні сповіщення e‑mail та трохи логіки через systemd. Вийде акуратна автоматизація задач, що допомагає своєчасно помічати проблеми і не бігти до консолі о 3-й ночі ✨.

Покроково: автоматизуємо відновлення fsck + e‑mail

Крок 1. Переконайтеся, що fsck виконується при завантаженні

systemd викликає fsck для розділів, якщо в /etc/fstab правильно задане поле перевірки (passno). Для кореня — 1, для інших — 2. Перевірте рядки у fstab:

# /etc/fstab (фрагмент)
UUID=...  /      ext4  defaults     0 1
UUID=...  /home  ext4  defaults     0 2

Додатково можна дозволити автоматичний ремонт на старті ядра (корисно для безнаглядних серверів):

# Додайте до параметрів ядра (GRUB):
fsck.repair=yes
# Опційно для тесту примусово:
fsck.mode=force

Після зміни /etc/default/grub не забудьте оновити завантажувач (наприклад, update-grub у Debian/Ubuntu).

Крок 2. Готуємо відправку пошти (msmtp + mailx)

Щоб отримувати e‑mail про результат перевірки, нам знадобляться легкі утиліти. Встановіть їх вашими улюбленими linux командами у термінал Linux:

# Debian/Ubuntu
sudo apt update && sudo apt install msmtp-mta bsd-mailx

# RHEL/CentOS/Fedora
sudo dnf install msmtp msmtp-mta mailx

# Arch/Manjaro
sudo pacman -S msmtp msmtp-mta s-nail

Налаштуйте /etc/msmtprc (приклад для SMTP-провайдера; використовуйте окремий «app password»):

sudo tee /etc/msmtprc >/dev/null <<'EOF'
# Глобальний профіль msmtp
account default
host smtp.example.com
port 587
auth on
user your_mail@example.com
passwordeval gpg --quiet --for-your-eyes-only --no-tty -d /root/.msmtp-pass.gpg
tls on
tls_trust_file /etc/ssl/certs/ca-certificates.crt
from your_mail@example.com
logfile /var/log/msmtp.log
EOF
sudo chmod 600 /etc/msmtprc

Порада безпеки: не зберігайте паролі відкритим текстом. Вище приклад із шифруванням пароля через gpg (створіть файл /root/.msmtp-pass.gpg самостійно).

Крок 3. Пишемо невеликий скрипт-надсилач

Створимо мінімальний «bash скрипти» для збирання журналу fsck і відправки e‑mail:

sudo tee /usr/local/sbin/fsck-email >/dev/null <<'EOF'
#!/usr/bin/env bash
set -euo pipefail

UNIT="${1:-systemd-fsck@.service}"
TO="admin@example.com"   # ЗМІНІТЬ на вашу адресу
HOST="$(hostname)"
SUBJ="[fsck] $UNIT on $HOST ($(date -Is))"

# Забираємо останні 500 рядків журналу по цій юніт-службі за поточне завантаження
BODY="$(journalctl -u "$UNIT" -b --no-pager -n 500 || true)"

# Якщо журнал порожній — все одно повідомимо, що був тригер
if [ -z "$BODY" ]; then
  BODY="No journal lines for $UNIT on $HOST."
fi

printf "%s\n" "$BODY" | mail -s "$SUBJ" "$TO"
EOF
sudo chmod +x /usr/local/sbin/fsck-email

Крок 4. Зв’язуємо все через systemd: OnFailure → e‑mail

Ми не переписуємо штатні юніти, а додаємо drop-in, який викличе наш сервіс при збої:

# Сервіс-шаблон, який відправляє пошту
sudo tee /etc/systemd/system/fsck-notify@.service >/dev/null <<'EOF'
[Unit]
Description=Send email on fsck failure for %i
After=network-online.target
Wants=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/local/sbin/fsck-email %i
EOF

# Drop-in для звичайних розділів
sudo install -d /etc/systemd/system/systemd-fsck@.service.d
sudo tee /etc/systemd/system/systemd-fsck@.service.d/notify.conf >/dev/null <<'EOF'
[Unit]
OnFailure=fsck-notify@%n.service
EOF

# Drop-in для кореневого розділу
sudo install -d /etc/systemd/system/systemd-fsck-root.service.d
sudo tee /etc/systemd/system/systemd-fsck-root.service.d/notify.conf >/dev/null <<'EOF'
[Unit]
OnFailure=fsck-notify@%n.service
EOF

sudo systemctl daemon-reload

Тепер, якщо fsck не зможе виправити помилки або завершиться збоєм, systemd тригерне fsck-notify@.service і ви отримаєте листа 📧.

Крок 5. Тестуємо обережно

Найбезпечніше тестувати на не критичному розділі або в тестовій ВМ. Для ext4 можна примусити перевірку:

# ДЛЯ ТЕСТОВОГО РОЗДІЛУ (НЕ ДЛЯ /)
sudo tune2fs -C 50 /dev/sdXN   # наблизити лічильник монтувань
sudo reboot

Або разово додайте параметр ядра fsck.mode=force і перезавантажтеся. Перевірте пошту й журнали:

journalctl -b -u 'systemd-fsck*' --no-pager

Альтернативні способи

  • Btrfs/XFS: замість fsck використовуйте рідні інструменти (btrfs scrub/btrfs check, xfs_repair). Логіка з OnFailure і сповіщенням аналогічна — лише змінюється команда перевірки.
  • Періодика поза завантаженням: через cron та systemd timers можна планувати перевірки не зайнятих (unmounted) розділів або LVM‑знімків. Це зручно для великих масивів, аби не затягувати boot‑час.
  • Сповіщення не тільки поштою: замініть рядок з mail на виклик вебхука в чат (наприклад, curl до Telegram Bot API) — структура служби залишиться тією самою.

GUI-спосіб (коли доречно)

У GNOME Disks (gnome-disk-utility) можна виконувати перевірку та ремонт розділів у зручному вікні. Це корисно для «ручних» разових дій на робочих станціях. Автоматизацію ж краще лишити systemd + скриптам, бо тоді працює навіть без графіки і в headless-сценаріях.

FAQ

Чи можна запускати fsck на змонтованому розділі?

Ні, для ext4 це небезпечно. fsck має працювати до монтування або на розділі, змонтованому лише для читання.

Що з XFS і Btrfs?

Для XFS використовуйте xfs_repair (і xfs_check у старих системах), для Btrfs — btrfs scrub/btrfs check. Ідея зі службою сповіщень та OnFailure лишається.

Я не отримав e‑mail. Де шукати причину?

Спочатку перегляньте log-файли Linux msmtp та журнал юніта сповіщень:

sudo tail -n 200 /var/log/msmtp.log
sudo journalctl -u 'fsck-notify@*' -b --no-pager

Часто допомагає перевірка SMTP‑доступу й коректності адреси отримувача.

Чи обов’язково ставити fsck.repair=yes?

Ні, це опція для безнаглядних систем. Вона дозволяє автоматичні виправлення. Якщо ви боїтеся втрати даних — залиште режим запитань за замовчуванням і приїжджайте руками підтверджувати.

Чи потрібні постійні журнали systemd?

Для зручності так: створіть /var/log/journal, перезапустіть systemd-journald. Тоді збережуться журнали між перезавантаженнями.

Чи вплине це на час завантаження?

Так, при реальній перевірці великих розділів boot сповільниться. Саме тому для великих об’ємів іноді краще періодичні перевірки через cron та systemd timers у вікна низького навантаження.

Порада від Kernelka

Заведіть окрему технічну скриньку для сповіщень, а в темі листа додавайте хостнейм і юніт — так легше фільтрувати й будувати правила. І не забувайте: автоматизація — це круто, але резервні копії ще крутіші 🛠️.

Підсумок

  • Увімкнули fsck на старті через правильний fstab та опціональні параметри ядра.
  • Додали drop-in до systemd‑fsck юнітів із OnFailure → наш сервіс.
  • Написали короткий скрипт для e‑mail і підключили msmtp/mailx.
  • Передбачили альтернативи для XFS/Btrfs і періодичні перевірки через cron та systemd timers.
  • Протестували обережно і перевірили журнали, щоб упевнитися, що ланцюжок працює.