この答え から Linux:/ dev/console、/ dev/tty、および/ dev/tty0の違い
ドキュメント から:
/dev/tty Current TTY device /dev/console System console /dev/tty0 Current virtual console
昔、
/dev/console
はシステム管理者コンソールでした。 TTYは、サーバーに接続されたユーザーのシリアルデバイスです。現在、/dev/console
と/dev/tty0
は現在の表示を表し、通常は同じです。たとえば、console=ttyS0
をgrub.conf
に追加することでオーバーライドできます。その後、/dev/tty0
はモニターになり、/dev/console
は/dev/ttyS0
になります。
" System console "により、/dev/console
が仮想コンソールのデバイスファイルであるのと同様に、/dev/tty{1..63}
はテキスト物理端末のデバイスファイルのように見えます。
「/dev/console
と/dev/tty0
は現在の表示を表し、通常は同じ」ということで、/dev/console
は仮想コンソールのデバイスファイルにもなるように思えます。 /dev/console
は/dev/tty0
よりも/dev/tty{1..63}
に似ています(/dev/tty0
は現在アクティブな仮想コンソールであり、/dev/tty{1..63}
のどれでもかまいません)。
/dev/console
とは何ですか?何に使うの?
Linuxカーネルでは、/dev/console
は/dev/tty
と同じ役割を果たしますか? (/dev/tty
は、プロセスのプロセスセッションの制御端末であり、pts、/dev/ttyn
、n
は1〜63、またはそれ以上の場合があります。)
他の返信 言及:
カーネルのドキュメントでは、
/dev/console
が5:1の番号が付けられたキャラクターデバイスとして指定されています。このキャラクターデバイスを開くと、「メイン」コンソールが開きます。これは、コンソールのリストの最後のttyです。
「コンソールのリスト」は ブートオプション のすべてのconsole=
を意味しますか?
「/dev/console
」は、5:1の番号が付いたキャラクターデバイスとして、/dev/console
が物理的なテキスト端末のデバイスファイル、つまりシステムコンソールであることを意味しますか? (ここでも、上で引用した最初の返信では、/dev/console
は/dev/tty0
と同じにすることができます。これは、物理的なテキスト端末ではなく、仮想コンソールです)
ありがとう。
/dev/console
は、主にカーネルのコンソールをユーザー空間に公開するために存在します。 デバイスに関するLinuxカーネルのドキュメント は今言う
コンソールデバイス
/dev/console
は、システムメッセージの送信先であり、シングルユーザーモードでのログインを許可するデバイスです。 Linux 2.1.71以降、/dev/console
はカーネルによって管理されます。以前のバージョンでは、/dev/tty0
、/dev/tty1
などの特定の仮想コンソール、またはシリアルポートプライマリ(tty*
ではなくcu*
)デバイスへのシンボリックリンクである必要があります、システムの構成に応じて。
/dev/console
、メジャー5とマイナー1のデバイスノードは、カーネルがシステム管理者と対話する主要な手段であると見なすものへのアクセスを提供します。これは、システムに接続された物理コンソールにすることができます(仮想コンソールの抽象化が上にあるため、tty0
または任意のttyN
を使用できます[〜#〜 ] n [〜#〜]は1〜63)、またはシリアルコンソール、ハイパーバイザコンソール、または点字デバイスです。カーネル自体は/dev/console
を使用しないことに注意してください。デバイスノードはカーネルではなくユーザースペース用です。ただし、/dev/console
が存在して使用可能であることを確認し、init
を標準入力、出力、および/dev/console
を指すエラーで設定します。
ここで説明するように、/dev/console
は、メジャーとマイナーが固定されたキャラクターデバイスです。これは、(物理デバイスではなく、カーネルにアクセスする手段のように)独立したデバイスであるため、/dev/tty0
またはその他のデバイス。これは、他の仮想コンソールまたは端末デバイスとは少し異なる機能を提供するため、独自のデバイス(5:0)である /dev/tty
の状況 に多少似ています。
「コンソールのリスト」は、確かにconsole=
ブートパラメータによって定義されたコンソールのリストです(存在しない場合はデフォルトのコンソール)。このように定義されたコンソールは、/proc/consoles
を見るとわかります。 /dev/console
は確かにアクセスを提供します これらの最後まで :
カーネルコマンドラインで複数のconsole =オプションを指定できます。出力はそれらすべてに表示されます。最後のデバイスは、
/dev/console
を開いたときに使用されます。
「/dev/console
とは何ですか?」 前の回答 で回答されています。おそらく、他の2つの質問に対する答えを知っていると、その答えはより明確になります。
Q1。 「物理端末自体を表すデバイスファイルとは何ですか?」
そのようなデバイスファイルはありません。
Q2。 「/dev/console
の用途」
Linuxでは、/dev/console
は、起動(およびシャットダウン)中にメッセージを表示するために使用されます。また、Stephen Kittの回答で指摘されているように、「シングルユーザーモード」にも使用されます。それを使用することは理にかなっています。
Unixの「古き良き時代」では、/dev/console
は専用の物理デバイスでした。しかし、これはLinuxには当てはまりません。
このように理解してみましょう。
/dev/tty{1..63}
と/dev/pts/n
は、デバイス自体を表すデバイスファイルであり、エミュレーションですが、プロセスやカーネルとは関係ありません。/dev/tty0
は、現在何かで使用されている/dev/tty{1..63}
の1つを表します(おそらくカーネルまたはシェルプロセス?)。/dev/tty
は、プロセスセッションで現在使用されている制御端末を表します。/dev/console
は、カーネルが現在使用している端末を表しますか?カーネルやプロセスに関係なく、物理端末自体を表すデバイスファイルとは何ですか?
/dev/tty{1..63}
の基盤となるデバイスはstruct con_driver
です。可能なすべてのドライバーを確認するには、チェックアウト https://elixir.bootlin.com/linux/v4.19/ident/do_take_over_console
これらの基本的なデバイスのデバイスファイルがありません!
それらを管理するための最小限のユーザースペースインターフェイスのみがあります。
$ head /sys/class/vtconsole/*/name
==> /sys/class/vtconsole/vtcon0/name <==
(S) dummy device
==> /sys/class/vtconsole/vtcon1/name <==
(M) frame buffer device
あなたが本当にもっと知りたいのなら、 the (M)
はモジュールを意味します 。つまりダミーのコンソールデバイスは、ロード可能なカーネルモジュールでは提供されません。これは、初期のカーネルイメージ(別名「builtin」)の一部です。
次に、/sys/class/vtconsole
の各サブディレクトリにあるbind
ファイルが表示され、アクティブなvtconsoleデバイスがわかります。アクティブなものに0
を書き込むと、ダミーに切り替わったように見えます。 (GUI VTは影響を受けていないようですが、テキストVTは機能しなくなります)。ダミーの1
を書き込んでも、アクティブにはなりません。どちらの方法でも、実際の方法に切り替えることができます。コードを正しく読んだ場合のトリックは、echo 1 > bind
はモジュール(?!)としてビルドされたコンソールドライバーに対してのみ機能することになっているということです。
framebufferコンソールの場合、具体的には、異なるフレームバッファーデバイス(/dev/fb0
...)を特定の仮想コンソールにバインドすることについて、いくつかの情報があります- https://kernel.org/doc/Documentation/fb/fbcon.txt 。これには、カーネルオプションfbcon:map=
またはcon2fbmap
というコマンドが含まれます。
もちろん、詳細はカーネルのバージョン、アーキテクチャ、ファームウェア、デバイス、ドライバなどによって異なる可能性があります。私は、上記のインターフェースを実際に使用する必要がありませんでした。カーネルは、ロード時にi915
/inteldrmfb
/呼び出したいものをすべて引き継ぐようにします。 vgacon
。
私のEFIマシンにはvgacon
がないようです。つまり、最初にダミーのコンソールを使用し、次に1.2秒後にfbcon
の上で実行されるefifb
に切り替えます。しかし、これまでのところ、詳細を気にする必要はありませんでした。うまくいきます。
$ dmesg | grep -C2 [Cc]onsole
[ 0.230822] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=4
[ 0.233164] NR_IRQS: 65792, nr_irqs: 728, preallocated irqs: 16
[ 0.233346] Console: colour dummy device 80x25
[ 0.233571] console [tty0] enabled
[ 0.233585] ACPI: Core revision 20180810
[ 0.233838] clocksource: hpet: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 133484882848 ns
--
[ 1.228393] efifb: scrolling: redraw
[ 1.228396] efifb: Truecolor: size=8:8:8:8, shift=24:16:8:0
[ 1.230393] Console: switching to colour frame buffer device 170x48
[ 1.232090] fb0: EFI VGA frame buffer device
[ 1.232110] intel_idle: MWAIT substates: 0x11142120
--
[ 3.595838] checking generic (e0000000 408000) vs hw (e0000000 10000000)
[ 3.595839] fb: switching to inteldrmfb from EFI VGA
[ 3.596577] Console: switching to colour dummy device 80x25
[ 3.596681] [drm] Replacing VGA console driver
[ 3.597159] [drm] ACPI BIOS requests an excessive sleep of 20000 ms, using 1500 ms instead
[ 3.599830] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
--
[ 3.657050] e1000e 0000:00:19.0 eth0: MAC: 11, PHY: 12, PBA No: FFFFFF-0FF
[ 3.657869] e1000e 0000:00:19.0 eno1: renamed from eth0
[ 4.711453] Console: switching to colour frame buffer device 170x48
[ 4.734356] i915 0000:00:02.0: fb0: inteldrmfb frame buffer device
[ 4.778813] Loading iSCSI transport class v2.0-870.
/dev/console
の用途」/ dev/consoleをTTYデバイスとして使用できます。たとえば、これに書き込むと、固有の文字デバイス番号も持つ特定の基本デバイスに書き込まれます。
多くの場合、/ dev/consoleは/ dev/tty0に関連付けられていますが、別のデバイスに関連付けられている場合もあります。
したがって、この場合、/ dev/consoleへの書き込みは/ dev/tty0への書き込みになります。また、/ dev/tty0への書き込みは、現在アクティブな/ dev/ttyNデバイスへの書き込みと同等です。
しかし、これは興味深い質問を引き起こします。 tty0
にアクセスすると、現在アクティブな仮想コンソールに応じて、異なる仮想コンソールにアクセスします。人々は実際にtty0
を何に使用し、同様にLinuxでconsole
を何に使用しますか?
技術的には、console
/tty0
から読み書きできます。たとえば、getty
を実行してtty0
にログインできるようにします。しかし、これは簡単なハックとしてのみ役立ちます。これは、Linuxの複数の仮想コンソールを利用できないことを意味します。
systemd
は、/ dev/consoleデバイスに関連付けられている属性をsysfs
で検索し、基礎となるTTYデバイスを検出します。これにより、systemd
が自動的にgetty
を生成し、ログインできるようになります。ユーザーがconsole=ttyS0
で起動してカーネルコンソールをセットアップしたときのシリアルコンソール。これは便利です。このコンソールを2つの異なる場所で構成する必要がなくなります。繰り返しますが、man systemd-getty-generator
を参照してください。ただし、systemd
が実際に/dev/console
を開くわけではありません。
システムのブートストラップ中は、sysfsがまだマウントされていない場合もあります。しかし、エラーと進行状況のメッセージをできるだけ早く表示できるようにしたいと考えています!したがって、ポイント1)に丸で囲みます。カーネルは、/dev/console
に接続されたstdin/stdout/stderrでPID 1を開始します。このシンプルなメカニズムを最初からセットアップできるのは非常に便利です。
Linuxコンテナ内では、/dev/console
のファイルは、キャラクターデバイス番号5:1
ではなく、別の何かとして作成される場合があります。代わりに、PTSデバイスファイルとして作成されます。次に、この/dev/console
ファイルを使用してログインすることは理にかなっています。 systemd
コンテナー内では、そのようなデバイスにログインできます。 man systemd-getty-generator
を参照してください。
このメカニズムは、systemd-nspawn
コマンドでコンテナーを実行するときに使用されます。 (私は、TTYでsystemd-nspawn
を実行したときだけだと思いますが、manページの検索からはわかりません)。
systemd-nspawn
は、コンテナの/dev/console
をホストからのPTSデバイスのバインドマウントとして作成します。つまり、このPTSデバイスはコンテナ内の/dev/pts/
内には表示されません。
PTSデバイスは、特定のdevpts
マウントに対してローカルです。 PTSデバイスは通常のルールの例外であり、デバイスはデバイス番号で識別されます。 PTSデバイスは、デバイス番号とdevpts
マウントの組み合わせによって識別されます。
緊急メッセージをconsole
/tty0
に書き込んで、ユーザーの現在の仮想コンソールに書き込むことができます。これは、コンソールに出力される緊急のカーネルメッセージ(man dmesg
を参照)と同様に、緊急のユーザー空間エラーメッセージに役立ちます。ただし、少なくともシステムの起動が完了したら、これを行うことは一般的ではありません。
rsyslogには このページの1つの例 があり、カーネルメッセージを/dev/console
に出力します。カーネルはデフォルトですでにそうしているので、これはLinuxでは無意味です。再度見つけることができない1つの例では、syslogメッセージが多すぎてコンソールをあふれさせて邪魔になりすぎるため、これをカーネル以外のメッセージに使用することはお勧めしません。
systemd-journaldにも同様に、すべてのログをコンソールに転送するオプションがあります。原則として、これは仮想環境でのデバッグに役立ちます。ただし、デバッグでは通常、代わりに/dev/kmsg
に転送します。これにより、カーネルログバッファーに保存され、dmesg
で読み取ることができます。カーネル自体によって生成されるメッセージと同様に、これらのメッセージは、現在のカーネル構成によってはコンソールにエコーされる場合があります。