Как приостановить (или перехватить) сообщения, пролетающие в конце последовательности запуска?


8

В конце «последовательности запуска» 1 я вижу, как очень быстро проходит длинный ряд диагностических сообщений, прямо перед тем, как я вижу приглашение входа в систему 2 .

AFAICT, большинство, если не все, строк, составляющих этот недолговечный вывод, начинаются с любой из строк, показанных ниже

[  OK  ]
[FAILED]

... где OK- зеленым, а FAILEDкрасным - 3 .

Эти сообщения мигают слишком коротко, чтобы я мог их прочитать.

Мой вопрос:

Есть ли способ облегчить чтение этих сообщений?


Возможные решения, которые приходят на ум, включают (в порядке предпочтения):

  1. ти (или просто перенаправлять) эти сообщения стенографических 4 в некоторый постоянная лог - файл;
  2. включение механизма пейджингового типа ( Press any key to continue...);
  3. вставка паузы (настраиваемой длины) после печати этих сообщений;
  4. включение некоторой клавиши (или комбинации клавиш) для приостановки вывода на экран 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
Lock
Pause/
Break


4
Разве journalctl -b(как пользователь root) не дает вам именно этого, то есть не видит точный текст этих сообщений в том виде, в котором они появились во время последовательности запуска ?
don_crissti

2
В зависимости от вашей системы вы можете найти сообщения в файле/var/log/boot.log
meuh

2
@Theophrastus: Я начинаю понимать, почему так много пользователей Linux терпеть не могут systemd, и я сам собираюсь вступить в их ряды ... Я отредактировал свой fn 4, чтобы объяснить (даже больше), почему journalctl --boot | grep -i fail, например, это не то, что Я ищу.
kjo

3
kjo, единственное различие, которое я вижу между сообщениями во время загрузки и сообщениями, зарегистрированными в, journal- это наличие [OK]/ [FAILED]. В остальном сообщения идентичны. Тем неsystemctl менее, правильный способ диагностировать / устранять неисправности неисправных устройств - это просто, чтобы вы знали. Я не знаю, можно ли приостановить процесс загрузки с помощью сочетания клавиш (говорят, что CTRL + S / CTRL + Q должно работать, но это не так, по крайней мере, на i915 / KMS). Тем не менее, вы можете отключить очистку загрузочных сообщений и прокрутить эти сообщения на TTY1 с помощью Shift + PgUp / Down.
don_crissti

2
Может быть, следующий Q / A дает что-то: superuser.com/questions/480370/…
Ральф Реннквист

Ответы:


1

Вы можете установить аргумент командной строки ядра (что-то вроде console=tty0 console=ttyS0,115200n8), чтобы вместо этого отправлять их на последовательную консоль, и тогда устройство, которое прослушивает последовательный порт, может просто зарегистрировать его, так как тогда это просто поток текста.

И systemd довольно глуп, если он все равно ничего не регистрирует. Openrc делает это в /var/log/rc.log. Также, если это не systemd, вы можете изменить inittab так, чтобы он просто не помещал туда getty / Xorg на tty1, и предотвращал бы переключение чего-либо (например, Xorg) в другое место, и старый текст мог бы оставаться на месте (как это было на старых предсистемный openSUSE). Или скопируйте его в другой tty (который, я думаю, делает syslog, а не inittab ... и вы можете увидеть, что многие установщики linux делают это на tty9 +). Если он переключается назад и назад, он просто не будет прокручиваться назад (shift + pgup) ), но, вероятно, будет иметь одну страницу вывода. Возможно, кто-то, кто знает больше о systemd, знает новый эквивалент inittab, и вы можете это изменить.


Если вы прочтете комментарии, вы увидите, что systemdэто заносит в журнал этот материал.
don_crissti
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.