¿Cómo pausar (o capturar) los mensajes que pasan volando al final de la secuencia de inicio?

Hacia el final de la "secuencia de inicio" ¹ , veo una larga serie de mensajes de diagnóstico que pasan muy rápido, justo antes de ver el mensaje de inicio de sesión ² .

AFACIO, la mayoría, si no todas, las líneas que componen esta salida de corta duración comienzan con cualquiera de las cadenas que se muestran a continuación

[  OK  ]
[FAILED]

... donde OKestá en verde y FAILEDestá en rojo ³ .

Estos mensajes parpadean demasiado brevemente para que pueda leerlos.

Mi pregunta es:

¿Hay alguna manera de hacer que estos mensajes sean más fáciles de leer?

Las posibles soluciones que vienen a la mente incluyen (en orden de preferencia):

1. teeing (o simplemente redirigiendo) esos mensajes textualmente ⁴ a algún archivo de registro persistente;
2. habilitar un mecanismo de tipo paginación ( Press any key to continue...);
3. insertar una pausa (de longitud configurable) después de imprimir esos mensajes;
4. habilitar alguna tecla (o combinación de teclas) para pausar la salida a la pantalla ⁵ .

EDITAR: según los comentarios que he recibido hasta ahora, debo concluir que la palabra literal en (1) anterior no se entiende o no se toma en serio, a pesar de que he enfatizado tanto como puedo. Lo haría parpadear si pudiera ...

EDIT2: la sugerencia que meuh dio en los comentarios me parece prometedora, pero aún no he podido hacerla funcionar. Esto es lo que hice:

Primero, agregué lo siguiente al final de /etc/rsyslog.conf:

# Save boot messages also to boot.log
local7.* /var/log/boot.log

... y reiniciado. Vi pasar los mensajes de diagnóstico habituales, pero no /var/log/boot.logse creó ningún archivo.

Luego, en el evento (ciertamente improbable) de que el /var/log/boot.logdebe existir antes de rsyslogpoder escribirle, ejecuté (como root):

touch /var/log/boot.log
chgrp adm /var/log/boot.log
chmod 640 /var/log/boot.log

... donde los comandos chgrpy chmodestaban destinados a hacer que la propiedad y los permisos de /var/log/boot.logcoincidan con los de todos los demás archivos de registro /var/log. Luego reinicié, vi los mensajes, etc. El archivo /var/log/boot.logpermaneció vacío después de este reinicio.

(Obtuve el mismo no resultado cuando cambié los permisos de /var/log/boot.loga 666).

I grep'ed la salida journalctl --booty los archivos bajo /var/logpara cualquier cosa que podría pensar en que pueden apuntar a algo mal con mi rsyslog, pero no encontró nada. (No estoy del todo familiarizado rsyslog, así que estoy seguro de que mi búsqueda fue bastante inepta).

Está claro que lo que he hecho hasta ahora no es suficiente para habilitar el registro deseado. Ahora estoy buscando lo que sea que me estoy perdiendo. Sin embargo, no he podido encontrar mucha documentación relevante. Por ejemplo, rsyslog.conf(5)ni se rsyslogd(8)digna a explicar qué local7es ( rsyslog.conf(5)es al menos lo suficientemente amable como para mencionarlo una vez, sin dar más información).

EDITAR3

Información de distribución:

$ 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

EDITAR4

Información adicional potencialmente relevante:

$ 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 Es decir, lo que ocurre cuando (re) inicio mi máquina.}

^{2 FWIW, multi-user.targetes mi valor predeterminado.}

^{3 El texto restante está todo en blanco sobre un fondo negro. Esto se aplica a la solicitud de inicio de sesión posterior.}

^{4 Encuentro completamente inaceptable cualquier solución que no me permita ver el texto exacto de estos mensajes tal como aparecieron durante la secuencia de inicio. Dado que, invariablemente, no estoy íntimamente familiarizado con ninguno de estos mensajes de diagnóstico, no es posible para mí reconocer todas las formas en que la información subyacente transmitida por el mensaje original puede ser parafraseada, difundida en varios otros mensajes , incluido en otros mensajes, etc. (Solo buscando en línea la redacción exacta del mensaje original tengo alguna esperanza de encontrar una solución al problema). Todo lo que he intentado hasta ahora, incluido journalctl -by dmesgno he podido darme los mensajes originales textualmente. Por ejemplo, cuando ejecuto el inicio solo puedo ver uno rojo FAILED, pero journalctl --boot | grep FAILED | wc -lregresa 0y journalctl --boot | grep -i FAILED | wc -l regresa 1086. Ninguno de estos es lo que estoy buscando.}

^{5 En mi sistema, tendría menos de un segundo para presionar dicha tecla o combinación de teclas, y no hay advertencia de cuándo comienza este breve intervalo. A menos que uno sea capaz de configurar la duración del intervalo durante el cual debe producirse tal pulsación de tecla, cualquier solución basada en la pulsación de tecla es demasiado poco práctica para ser algo más que una maniobra de último recurso. Además, FWIW, intenté presionar la tecla o la tecla cuando aparecieron los mensajes, pero ninguno hizo ninguna diferencia.Scroll
LockPause/
Break}

En su lugar, puede configurar un argumento de línea de comando del kernel (algo así console=tty0 console=ttyS0,115200n8) para enviarlos a una consola serie, y luego el dispositivo que escucha en el puerto serie simplemente puede registrarlo, ya que es solo una secuencia de texto.

Y systemd es bastante tonto si de todos modos no registra esto. Openrc lo hace en /var/log/rc.log. Además, si no fuera systemd, probablemente podría modificar inittab para simplemente no poner un getty / Xorg allí en tty1, y evitar que cualquier cosa (como Xorg) cambie a otro lado, y el texto antiguo podría quedarse (tal como lo hizo en el antiguo pre-systemd openSUSE). O cópielo en otro tty (que creo que es syslog haciendo eso en lugar de inittab ... y es posible que vea muchos instaladores de Linux haciendo esto en tty9 +) Si se apaga y retrocede, simplemente no se desplazará hacia atrás (shift + pgup ), pero probablemente tendrá una página de salida. Quizás alguien que sepa más sobre systemd conozca el nuevo equivalente a inittab y usted puede cambiar eso.