슈퍼 너드에 대한 추가 설명

슈퍼 너드에 대한 추가 설명

지금까지 저는 시스템 직렬 포트에서 시작될 때 커널과 systemd가 첫 번째 로그 메시지를 출력하도록 관리했습니다. 또한, 저널드는 시작 프로세스가 (거의) 완료된 후에도 계속해서 모든 내용을 시리얼에 기록합니다(예: 서비스가 무언가를 기록할 때). 그러나 짧은 시간 동안 직렬 콘솔에서는 어떤 출력도 얻지 못합니다. 이는 systemd가 장치를 시작한 직후에 항상 발생하며 dev-mqueue.mount결국 로깅은 계속해서 메시지를 표시합니다 Console: switching to colour frame buffer device 240x67. 따라서 직렬 콘솔은 약을 놓칩니다. 5초 동안의 중요한 로그 메시지. 내 재시도는 모두 이렇습니다. 이 시점에서 왜 로깅이 계속되는지 잘 모르겠습니다.

내 질문은 다음과 같습니다이 5초 동안 직렬 콘솔에 무언가를 계속 기록하려면 어떻게 해야 합니까?

시스템 메시지:(시스템 관련 문제인 경우):

  • 시스템: Raspberry Pi 4B(4GB RAM)
  • 운영 체제: Debian GNU/Linux(2023.11.09 이미지 출처:여기)
    • 더 멀리apt update && apt upgrade
    • 핵심:Linux rpi4-20231108 6.1.0-17-arm64 #1 SMP Debian 6.1.69-1 (2023-12-30) aarch64 GNU/Linux
    • SD 카드에서 부팅
  • GPIO 핀을 통해 RPi4의 기본 직렬 출력 사용
  • picocom직렬 입력 어댑터: USB를 통해 Debian 데스크탑 시스템에서 사용하기 위한 CP2101(3.3V 모드로 설정)

현재 구성:(성공적인 부팅 후 직렬을 통해 로그인해야 하는 다른 사용자에게도 도움이 될 수 있습니다.)

RPi의 기본 직렬 콘솔을 활성화하려면 enable_uart=1이를 설정해야 합니다 /boot/firmware/config.txt(대부분의 이미지에서 기본값). 추가적으로 커널은 직렬 포트를 콘솔로 사용해야 한다는 것을 알아야 합니다. RPi4에서는 /dev/ttyS1핀 8과 10을 통해 호출할 수 있습니다(참조:여기). 또한 systemd와 Journald는 이를 알아야 합니다. 그래서 나는 다음을 수행했습니다.

/etc/default/raspi-config내 설정 CONSOLES="tty0 ttyS1,115200"명령 커널 에서 . initramfs에서 직접 로깅하도록 /etc/default/raspi-extra-cmdline구성을 추가했습니다 . systemd.journald.forward_to_console=1오랜 시간이 지난 후 update-initramfs -u -k all이제 /boot/firmware/cmdline.txt다음이 포함됩니다 console=tty0 console=ttyS1,115200 systemd.journald.forward_to_console=1 root=LABEL=RASPIROOT rw fsck.repair=yes net.ifnames=0 rootwait.

/etc/systemd/journald.conf.d/forwardto-ttyS1.conf다음 내용으로 Journald post-initramfs용 파일을 만들었습니다 .

[Journal]
ForwardToConsole=yes
TTYPath=/dev/ttyS1
MaxLevelConsole=info

마지막으로 getty가 직렬 포트에 로그인 프롬프트를 표시하지 않도록 비활성화했습니다.이 특정 tty의 경우달리기로.systemctl mask [email protected]

내가 지금까지 시도한 것 :

  • 추가 systemd.log_target=consoleloglevel=7cmdline에: 아무것도 변경되지 않았습니다.
  • cmdline에 추가됨 systemd.log_target=kmsg: 아무것도 변경하지 않았습니다.
  • 전송 속도를 115200에서 9600으로 변경: 시작 속도가 느려지지만 여전히 5초 동안 아무것도 기록되지 않습니다.

전체 직렬 출력(무시네마 녹음,115200그리고9600) 및 115200 및 9600 전송 속도로 실행되는 로그 게시여기(참고: CPU 사용량이 높을 수 있습니다., 읽다위안입니다).

문맥:내가 이 로그 출력을 원한 이유는 내가 맞춤 설계한 Debian 이미지 중 하나가 부팅 시 드라이브 읽기/쓰기를 마운트하여 최종적으로 로그 파일을 저장하기 전에 충돌했기 때문입니다. 화면 출력의 새로 고침 빈도가 너무 느려서 마지막 중요한 메시지를 표시할 수 없어 충돌 이유를 설명할 수 있습니다. 충돌 직전의 이러한 메시지도 직렬로 기록되지 않으므로 디버깅이 거의 불가능합니다.

답변1

브라우저에서 asciinema 기록을 재생하여 문제가 문서화되지 않았음을 발견했습니다. 이는 tmux로 인해 발생하는 "표시 문제"입니다. tmux 세션 외부에서(또는 직렬에 연결된) asciinema를 볼 때 로그는 계속되고 완료된 것으로 나타납니다. 그러나 tmux에서는 기본 구성으로도 충돌이 발생합니다. (만약에 대비해 xterm과 KDE의 Konsole, bash와 zsh에서 tmux를 사용하여 테스트했습니다.)

이로 인해 발생할 수 있는 혼란에 대해 사과드립니다. 혹시라도 혹시나 같은 문제를 겪으시는 분이 계시고, 제 답변이 도움이 되실까 봐 거의 불가능할 것 같아 계속 질문을 하게 되네요...

슈퍼 너드에 대한 추가 설명

이 문제는 이 줄이 인쇄되기 때문에 발생합니다.탈출하지 않은(이것은 asciinema가 선행 공백을 잘라서 줄을 저장하는 방법입니다.)

Mounting \u001b[0;1;39mdev-mqueue.mount\u001b…POSIX Message Queue File System...\r\n

이것이스케이프 문자 \u001b터미널 에뮬레이터(라고 함)에서 작업을 호출하기 위해 전송됩니다.ANSI 이스케이프 시퀀스. 요약하면 \u001b[0;1;39m"재설정"( 0), "굵게/강도 높이기"( 1) 및 "기본 전경색"( 39)과 같은 것입니다. 그 이후의 코드는 모든 것을 다시 재설정해야 하지만 systemd-journald는 원래 줄이 너무 길다고 주장하므로 중간 부분을 타원()으로 대체하여 원래 줄을 자릅니다(이는 다음과 같이 해석됨).여기), 이스케이프 문자는 하나만 남깁니다.

대부분의 터미널 에뮬레이터(Linux 가상 tty 포함)는 이를 잘 처리하는 것처럼 보이지만(최대 몇 문자만 인쇄하지 않음) tmux는 계속해서 이스케이프 코드를 구문 분석하므로 tmux가 5초 동안 아무 것도 인쇄하지 않습니다.

관련 정보