À quoi sert `/dev/console` ?

/dev/console existe principalement pour exposer la console du noyau à l'espace utilisateur. La documentation du noyau Linux sur les appareils indique désormais

L'appareil de la console, /dev/console , est l'appareil auquel les messages système doivent être envoyés et sur lequel les connexions doivent être autorisées en mode mono-utilisateur. À partir de Linux 2.1.71, /dev/console est géré par le noyau ; pour les versions précédentes, il doit s'agir d'un lien symbolique vers /dev/tty0 , une console virtuelle spécifique telle que /dev/tty1 , ou à un port série primaire (tty* , pas cu* ) périphérique, en fonction de la configuration du système.

/dev/console , le nœud de périphérique avec le majeur 5 et le mineur 1, donne accès à tout ce que le noyau considère comme son principal moyen d'interagir avec l'administrateur système ; cela peut être une console physique connectée au système (avec l'abstraction de la console virtuelle en haut, elle peut donc utiliser tty0 ou n'importe quel ttyN où N est compris entre 1 et 63), soit une console série, soit une console hyperviseur, soit encore une borne Braille. Notez que le noyau lui-même n'utilise pas /dev/console :les nœuds de périphériques sont pour l'espace utilisateur, pas pour le noyau ; il vérifie cependant que /dev/console existe et est utilisable, et définit init avec son entrée standard, sa sortie et son erreur pointant vers /dev/console .

Comme décrit ici, /dev/console est un périphérique de caractères avec un majeur et un mineur fixes car il s'agit d'un périphérique séparé (comme dans, un moyen d'accéder au noyau ; pas un périphérique physique), non équivalent à /dev/tty0 ou tout autre appareil. C'est un peu similaire à la situation avec /dev/tty qui est son propre appareil (5:0) car il offre des fonctionnalités légèrement différentes de celles des autres consoles virtuelles ou terminaux.

La "liste des consoles" est bien la liste des consoles définie par le console= paramètres de démarrage (ou la console par défaut, s'il n'y en a pas). Vous pouvez voir les consoles définies de cette manière en regardant /proc/consoles . /dev/console donne en effet accès au dernier d'entre eux :

Vous pouvez spécifier plusieurs options console=sur la ligne de commande du noyau. La sortie apparaîtra sur chacun d'eux. Le dernier appareil sera utilisé lorsque vous ouvrirez /dev/console .

"Qu'est-ce que /dev/console ?" est répondu dans la réponse précédente. Peut-être que cette réponse est plus claire lorsque vous connaissez les réponses aux deux autres questions.

Q1. "Quel est le fichier de périphérique représentant le terminal physique lui-même ?"

Il n'y a pas de fichier de périphérique de ce type.

Q2. "Qu'est-ce que /dev/console utilisé pour ?"

Sous Linux, /dev/console est utilisé pour afficher des messages lors du démarrage (et de l'arrêt). Il est également utilisé pour le "mode mono-utilisateur", comme indiqué dans la réponse de Stephen Kitt. Il n'y a pas grand-chose d'autre pour lequel il est logique de l'utiliser.

"Au bon vieux temps" d'Unix, /dev/console était un appareil physique dédié. Mais ce n'est pas le cas sous Linux.

Preuve connexe

1. "Quel est le fichier de périphérique représentant le terminal physique lui-même ?"

Permettez-moi d'essayer de comprendre de cette façon. /dev/tty{1..63} et /dev/pts/n sont des fichiers de périphérique représentant les périphériques eux-mêmes (bien qu'il s'agisse d'émulations), sans relation avec le processus ou le noyau. /dev/tty0 représente celui en /dev/tty{1..63} qui est actuellement utilisé par quelque chose (peut-être le noyau ou le processus shell ?). /dev/tty représente le terminal de contrôle actuellement utilisé par une session de processus. /dev/console représente le terminal actuellement utilisé par le noyau ?

Quel est le fichier de périphérique représentant le terminal physique lui-même, sans relation avec le noyau ou le processus ?

Le ou les appareils sous-jacents pour /dev/tty{1..63} sont struct con_driver . Pour voir tous les pilotes possibles, consultez https://elixir.bootlin.com/linux/v4.19/ident/do_take_over_console

Il n'y a pas de fichier de périphérique pour ces périphériques sous-jacents !

Il n'y a qu'une interface utilisateur minimale pour les gérer.

$ head /sys/class/vtconsole/*/name
==> /sys/class/vtconsole/vtcon0/name <==
(S) dummy device

==> /sys/class/vtconsole/vtcon1/name <==
(M) frame buffer device

Si vous voulez vraiment en savoir plus, le (M) signifie module. C'est à dire. le dispositif de console factice n'est pas fourni par un module de noyau chargeable ; il fait partie de l'image initiale du noyau (alias "builtin").

Deuxièmement, le bind fichier dans chaque sous-répertoire de /sys/class/vtconsole apparaît pour vous dire quel périphérique vtconsole est actif. Si j'écris 0 à l'actif, il semble passer au factice. (Les VT GUI ne semblent pas affectés, mais les VT textuels cessent de fonctionner). Écrire 1 pour le mannequin on ne l'active pas. L'une ou l'autre méthode fonctionne pour revenir à la vraie. Si j'ai bien lu le code, l'astuce est que echo 1 > bind n'est censé fonctionner que pour les pilotes de console construits en tant que module (?!).

Pour framebuffer consoles spécifiquement, il y a plus d'informations sur la liaison de différents périphériques framebuffer (/dev/fb0 ...) à des consoles virtuelles spécifiques dans https://kernel.org/doc/Documentation/fb/fbcon.txt . Cela implique une option de noyau fbcon:map= ou une commande appelée con2fbmap .

Bien sûr, les détails peuvent varier selon les différentes versions du noyau, les architectures, les firmwares, les périphériques, les pilotes, etc. Je n'ai jamais vraiment eu à utiliser l'une des interfaces ci-dessus. Le noyau laisse juste i915 / inteldrmfb / quel que soit le nom que vous voulez lui donner, il prend le relais lors du chargement, en remplaçant par ex. vgacon .

Il semble que ma machine EFI n'ait jamais vgacon . Donc, premièrement, il utilise une console factice, et deuxièmement, après 1,2 seconde, il passe à fbcon , s'exécutant au-dessus de efifb . Mais jusqu'à présent, je n'ai pas eu à me soucier des détails; ça marche.

$ 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.

2. "Qu'est-ce que /dev/console utilisé pour ?"

Vous pouvez utiliser /dev/console comme périphérique TTY. Écrire dessus, par exemple, écrira sur un périphérique sous-jacent spécifique, qui aura également son propre numéro de périphérique de caractère.

Souvent, /dev/console est lié à /dev/tty0, mais parfois il peut être lié à un autre appareil.

Donc, dans ce cas, écrire dans /dev/console écrira dans /dev/tty0. Et à son tour, écrire sur /dev/tty0 équivaut à écrire sur n'importe quel périphérique /dev/ttyN actuellement actif.

Mais cela soulève une question intéressante. Accéder au tty0 accédera à différentes consoles virtuelles, selon celle qui est actuellement active. Qu'est-ce que les gens utilisent réellement ? tty0 pour, et de même qu'est-ce que console utilisé sous Linux ?

1. Techniquement, vous pouvez lire et écrire à partir de console / tty0 , par exemple en exécutant un getty pour autoriser la connexion sur tty0 . Mais cela n'est utile que comme un hack rapide. Parce que cela signifie que vous ne pouvez pas profiter des multiples consoles virtuelles de Linux.

2. systemd regarde dans sysfs pour un attribut associé au périphérique /dev/console, pour détecter le périphérique TTY sous-jacent. Cela permet systemd pour générer automatiquement un getty et autoriser la connexion, par ex. une console série, lorsque l'utilisateur configure une console noyau en démarrant avec console=ttyS0 . C'est pratique; cela évite d'avoir à configurer cette console à deux endroits différents. Encore une fois, voir man systemd-getty-generator . Cependant, systemd n'ouvre pas réellement /dev/console pour cela.

3. Pendant le démarrage du système, vous n'avez peut-être même pas encore monté sysfs. Mais vous voulez pouvoir afficher les messages d'erreur et de progression dès que possible ! Nous tournons donc autour du point 1). Le noyau démarre le PID 1 avec stdin/stdout/stderr connecté à /dev/console . C'est très agréable d'avoir ce mécanisme simple mis en place dès le départ.

4. Dans un conteneur Linux, le fichier /dev/console peut être créé comme quelque chose de différent - pas le numéro de périphérique de caractère 5:1 . Au lieu de cela, il peut être créé en tant que fichier de périphérique PTS. Il serait alors logique de se connecter via ce /dev/console dossier. systemd à l'intérieur d'un conteneur permettra de se connecter sur un tel appareil ; voir man systemd-getty-generator .

   Ce mécanisme est utilisé lorsque vous exécutez un conteneur avec le systemd-nspawn commande. (Je pense que lorsque vous exécutez systemd-nspawn sur un ATS, bien que je ne puisse pas le dire en cherchant dans la page de manuel).

   systemd-nspawn crée le /dev/console du conteneur en tant que montage lié d'un périphérique PTS à partir de l'hôte. Cela signifie que cet appareil PTS n'est pas visible à l'intérieur de /dev/pts/ à l'intérieur du conteneur.

   Les appareils PTS sont locaux à un devpts spécifique monter. Les appareils PTS sont une exception à la règle normale, selon laquelle les appareils sont identifiés par leur numéro d'appareil. Les appareils PTS sont identifiés par la combinaison de leur numéro d'appareil et de leur devpts monter.

5. Vous pouvez écrire des messages urgents au console / tty0 , pour écrire dans la console virtuelle actuelle de l'utilisateur. Cela peut être utile pour les messages d'erreur urgents de l'espace utilisateur, similaires aux messages urgents du noyau qui sont imprimés sur la console (voir man dmesg ). Cependant, il n'est pas courant de le faire, au moins une fois que le système a fini de démarrer.

   rsyslog a un exemple sur cette page, qui imprime les messages du noyau sur /dev/console; cela ne sert à rien sous Linux car le noyau le fera déjà par défaut. Un exemple que je n'arrive pas à retrouver indique que ce n'est pas une bonne idée de l'utiliser pour les messages non liés au noyau car il y a trop de messages syslog, vous inondez votre console et cela gêne trop.

   systemd-journald a également des options pour transférer tous les journaux vers la console. En principe, cela peut être utile pour le débogage dans un environnement virtuel. Bien que, pour le débogage, nous transmettions généralement à /dev/kmsg Au lieu. Cela les enregistre dans le tampon du journal du noyau afin que vous puissiez les lire avec dmesg . Comme les messages générés par le noyau lui-même, ces messages peuvent être renvoyés à la console en fonction de la configuration actuelle du noyau.