Практически все мы (администраторы FreeBSD) при работе с настоящей системой сталкивались со случаями, когда начинаются странные произвольные перегрузки удаленного сервера. Вроде бы поставил, всё настроил, железо нормальное – должно работать, а не тут то было. Заказчик звонит, он в панике, постоянно ребуты. В результате применения «магического хрустального шара» выясняем, что оказывается это не само оно, а имело место быть пропадание электропитания. В FreeBSD, как правило, используется файловая система UFS, которая крайне чувствительна к таким вещам. Даже выключение технологии Soft-Update не спасает нас, поскольку файловая система при аварийном выключении остается «неочищенной». Ну и потом внезапно начинаются ребуты. Давайте обратимся к документации, а конкретно, к файлу /etc/defaults/rc.conf. Вот то, что касается утилиты проверки файловых систем fsck.
root_rw_mount="YES" # Set to NO to inhibit remounting root read-write.
fsck_y_enable="NO" # Set to YES to do fsck -y if the initial preen fails.
fsck_y_flags="" # Additional flags for fsck -y
background_fsck="YES" # Attempt to run fsck in the background where possible.
background_fsck_delay="60" # Time to wait (seconds) before starting the fsck.
netfs_types="nfs:NFS nfs4:NFS4 smbfs:SMB portalfs:PORTAL nwfs:NWFS" #Net filesystems.
extra_netfs_types="NO" # List of network extra filesystem types for delayed
# mount at startup (or NO).
Т.е. при старте системы принудительная проверка не запускается, она запускается в фоновом режиме в ключом -b с задержкой 60 секунд. Интересно, что исправить примонтированную в режиме чтения-записи файловую систему fsck не может, зато панику ядра и аварийный ребут из-за попыток локирования используемых уже системой файлов вызывает запросто, чем еще более усугубляет дело. Спастись можно только имея доступ к консоли, необходимо загрузиться в однопользовательском режиме и проверить все файловые системы вручную. Практика показала, что если во вовремя не провести подобную процедуру сервер сам разрушит свою файловую систему до такого состояния, что проверка в однопользовательском режиме не закончится успешно, там появляются критические ошибки, которые fsck исправить не способно, ради интереса можете погуглить. Мне пришлось снимать жесткий диск и подключать его через адаптер USB-IDE/SATA к ноутбуку с FreeBSD. После ТРЁХ циклов fsck все ошибки были, наконец, исправлены. Вам нужен такой постоянный БДСМ? Лично мне нет. Поэтому в файл /etc/rc.conf я добавил строки:
fsck_y_enable="YES"
background_fsck="NO"
Скрепя сердце, «передернул» питание одному из неответственных серверов, который гарантированно не загружается корректно после подобных сбоев питания. Сообщения не от ядра при загрузке системы не заносятся в логи, поэтому приведу непосредственно фотоотчет.
Простите за неважное качество второго фото, но идея понятна: после загрузки ядра началась проверка файловых систем и их «очистка», процесс прошел успешно, поднялся сетевой интерфейс (опять простите за риалтек) и загрузка системы продолжилась в нормальном режиме. Таким образом, настоятельно рекомендую на ВСЕХ удаленных серверах под управлением FreeBSD обязательно вносить означенные строки в файл /etc/rc.conf – это избавит от лишнего БДСМ в самый неподходящий момент.
