これまで、私はシステムシリアルポートから起動したときにカーネルと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=console
とloglevel=7
cmdlineに:何も変更されていません。 - cmdlineに追加されました
systemd.log_target=kmsg
:何も変更していません。 - 転送速度を115200から9600に変更:開始速度が遅くなりますが、まだ5秒間何も記録されません。
フルシリアル出力(ムシネマ録音、115200そして9600) および 115200 および 9600 ボーレートで実行されるログの公開ここ(注:CPU使用率が高い場合があります。、読む慰めです)。
コンテキスト:私がこのログを出力したいのは、私がカスタム設計したDebianイメージの1つが起動時にドライブの読み取り/書き込みをマウントして最終的にログファイルを保存する前にクラッシュしたためです。画面出力の更新頻度が遅すぎるため、最後の重要なメッセージを表示できないため、競合の理由を説明できます。衝突直前のこれらのメッセージも直列に書き込まれないため、デバッグはほとんど不可能です。
答え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は元の行が長すぎると主張するので、…
中間部分を楕円()で置き換えて元の行を切り捨てます(これは次のように解釈されます)。ここ)、エスケープ文字は1つだけ残します。
ほとんどのターミナルエミュレータ(Linux仮想ttyを含む)はこれをうまく処理しているようですが(最大数文字だけを印刷しない)、tmuxはエスケープコードを解析し続けるため、tmuxは5秒間何も印刷しません。