sshd
- это демон. Вы можете использовать флаг -q
с клиентом ( ssh
).
При подключении к домашним машинам включите флаг -q в команду ssh
(например, ssh -q user @ host
). В качестве альтернативы, если это не сработает, вы можете попробовать перенаправить stderr на / dev / null, подключившись к своим домашним машинам, например ssh user @ host 2> / dev / null
.
journalctl -k
показывает сообщения в журнале, которые пришли из ядра. dmesg
показывает содержимое кольцевого буфера ядра. Оба показывают ошибки ядра, включая сообщения об ошибках драйверов файловой системы; это точно.
Ничто из этого не исходит из e2fsck
. Журнал файловой системы не имеет ничего общего с «журналом», к которому обращается journalctl
. Выполнение e2fsck
в смонтированной файловой системе может привести к неверным результатам, поскольку данные, поддерживаемые драйвером файловой системы, не обязательно находятся на диске во время работы e2fsck
и могут измениться во время работы e2fsck
.
Примечание для дополнительного контекста :во время загрузки, некоторые конфигурации systemd
будут запускать команду fsck
в корневой файловой системе , пока она смонтирована только для чтения . Согласно предупреждениям в man e2fsck
, это не идеально. Предпочтительной конфигурацией является использование initramfs, который выполняет обычныйfsck
перед тем, как вообще смонтирует корневую файловую систему.
(У нас есть существующий Q/A, который объясняет это, но это беспорядок ).
e2fsck -n
в файловой системе, смонтированной только для чтения печатает действительные результаты.
Другое дело, является ли e2fsck
без -n
полностью «безопасным». (А если это небезопасно, то тоже есть риск получения недействительных результатов ). Я был бы осторожен с этим :-). Но я полагаю, вы можете быть уверены, что то, что делает systemd
, не «менее безопасно», чем сценарии предыдущего поколения.
Я думаю, чтобы уменьшить риски, правило таково, что если такому fsck
пришлось внести какие-либо изменения, система должна быть немедленно перезагружена.