В конце «последовательности запуска» 1 я вижу, как очень быстро проходит длинный ряд диагностических сообщений, прямо перед тем, как я вижу приглашение входа в систему 2 .
AFAICT, большинство, если не все, строк, составляющих этот недолговечный вывод, начинаются с любой из строк, показанных ниже
[ OK ]
[FAILED]
... где OK
- зеленым, а FAILED
красным - 3 .
Эти сообщения мигают слишком коротко, чтобы я мог их прочитать.
Мой вопрос:
Есть ли способ облегчить чтение этих сообщений?
Возможные решения, которые приходят на ум, включают (в порядке предпочтения):
- ти (или просто перенаправлять) эти сообщения стенографических 4 в некоторый постоянная лог - файл;
- включение механизма пейджингового типа (
Press any key to continue...
); - вставка паузы (настраиваемой длины) после печати этих сообщений;
- включение некоторой клавиши (или комбинации клавиш) для приостановки вывода на экран 5 .
РЕДАКТИРОВАТЬ: основываясь на комментариях, которые я получил до сих пор, я должен сделать вывод, что дословное слово в (1) выше либо не понято, либо не воспринимается всерьез, даже несмотря на то, что я подчеркнул как можно больше. Если бы я мог ...
РЕДАКТИРОВАТЬ 2: предложение, которое meuh дал в комментариях, кажется мне многообещающим, но я еще не смог заставить его работать. Вот что я сделал:
Сначала я добавил следующее в конце /etc/rsyslog.conf
:
# Save boot messages also to boot.log
local7.* /var/log/boot.log
... и перезагрузился. Я видел обычные диагностические сообщения, но /var/log/boot.log
файл не был создан.
Затем, в (по общему признанию маловероятном) событии, /var/log/boot.log
которое должно существовать до того, как он rsyslog
сможет записать в него, я выполнил (как root):
touch /var/log/boot.log
chgrp adm /var/log/boot.log
chmod 640 /var/log/boot.log
... где chgrp
и chmod
команды должны были оформить право собственности и разрешения /var/log/boot.log
совпадают все остальные файлы журнала под /var/log
. Затем я перезагрузился, увидел сообщения и т. Д. Файл /var/log/boot.log
остался пустым после этой перезагрузки.
(Я получил тот же не-результат, когда я изменил разрешения /var/log/boot.log
на 666
.)
Я grep
редактировал вывод journalctl --boot
и файлы /var/log
для всего, что мог придумать, что может указывать на что-то не так с моим rsyslog
, но ничего не нашел. (Я совсем не знаком с этим rsyslog
, поэтому я уверен, что мои поиски были довольно неумелыми.)
Понятно, что того, что я сделал, недостаточно для включения желаемой регистрации. Я сейчас ищу то, что мне не хватает. Однако я не смог найти много соответствующей документации. Например, ни rsyslog.conf(5)
не rsyslogd(8)
достоин, ни объясняет, что local7
есть ( rsyslog.conf(5)
по крайней мере, достаточно любезен, чтобы упомянуть об этом один раз, не давая никакой дополнительной информации).
EDIT3
Распространение информации:
$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 8.3 (jessie)
Release: 8.3
Codename: jessie
$ uname -a
Linux myhost 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt20-1+deb8u3 (2016-01-17) x86_64 GNU/Linux
EDIT4
Дополнительная потенциально значимая информация:
$ cat /lib/systemd/system/rsyslog.service
[Unit]
Description=System Logging Service
Requires=syslog.socket
Documentation=man:rsyslogd(8)
Documentation=http://www.rsyslog.com/doc/
[Service]
Type=notify
ExecStart=/usr/sbin/rsyslogd -n
StandardOutput=null
Restart=on-failure
[Install]
WantedBy=multi-user.target
Alias=syslog.service
$ cat /proc/$(pgrep rsyslogd)/limits
Limit Soft Limit Hard Limit Units
Max cpu time unlimited unlimited seconds
Max file size unlimited unlimited bytes
Max data size unlimited unlimited bytes
Max stack size 8388608 unlimited bytes
Max core file size 0 unlimited bytes
Max resident set unlimited unlimited bytes
Max processes 128529 128529 processes
Max open files 1024 4096 files
Max locked memory 65536 65536 bytes
Max address space unlimited unlimited bytes
Max file locks unlimited unlimited locks
Max pending signals 128529 128529 signals
Max msgqueue size 819200 819200 bytes
Max nice priority 0 0
Max realtime priority 0 0
Max realtime timeout unlimited unlimited us
$ sudo ls /proc/$(pgrep rsyslogd)/fd | wc -l
10
1 Т.е. то , что происходит , когда я (перо) загрузка моей машины.
2 FWIW, multi-user.target
это мой по умолчанию.
3 Оставшийся текст полностью белый на черном фоне. Это верно для последующего приглашения на вход.
4 Я считаю совершенно неприемлемым любое решение, которое не позволяет мне видеть точный текст этих сообщений в том виде, в котором они появились во время последовательности запуска. Поскольку неизменно я не очень хорошо знаком с какими-либо из этих диагностических сообщений, я не могу распознать все способы, которыми можно перефразировать основную информацию, передаваемую в исходном сообщении, и распределить ее по множеству других сообщений. , включены в другие сообщения и т. д. (Только при поиске точной формулировки исходного сообщения в Интернете у меня есть надежда найти решение проблемы.) Все, что я пробовал до сих пор, включая journalctl -b
и dmesg
не смогло дать мне дословно оригинальные сообщения, Например, когда я запускаю автозагрузку, я вижу только один красный FAILED
, но journalctl --boot | grep FAILED | wc -l
возвращается 0
и journalctl --boot | grep -i FAILED | wc -l
возвращается 1086
. Ни то, ни другое я не ищу.
5 В моей системе у меня было бы меньше секунды, чтобы нажать такую клавишу или комбинацию клавиш, и нет никакого предупреждения о том, когда начинается этот короткий интервал. Если не удается настроить продолжительность интервала, в течение которого должно происходить такое нажатие клавиши, любые решения, основанные на нажатии клавиш, слишком непрактичны, чтобы быть чем-то большим, чем маневр в крайнем случае. Кроме того, FWIW, я пробовал нажимать клавишу или, когда сообщения мигали, но ни одно не имело никакого значения.Scroll
LockPause/
Break
/var/log/boot.log
systemd
, и я сам собираюсь вступить в их ряды ... Я отредактировал свой fn 4, чтобы объяснить (даже больше), почему journalctl --boot | grep -i fail
, например, это не то, что Я ищу.
journal
- это наличие [OK]
/ [FAILED]
. В остальном сообщения идентичны. Тем неsystemctl
менее, правильный способ диагностировать / устранять неисправности неисправных устройств - это просто, чтобы вы знали. Я не знаю, можно ли приостановить процесс загрузки с помощью сочетания клавиш (говорят, что CTRL + S / CTRL + Q должно работать, но это не так, по крайней мере, на i915 / KMS). Тем не менее, вы можете отключить очистку загрузочных сообщений и прокрутить эти сообщения на TTY1 с помощью Shift + PgUp / Down.
journalctl -b
(как пользователь root) не дает вам именно этого, то есть не видит точный текст этих сообщений в том виде, в котором они появились во время последовательности запуска ?