Je travaille avec une plate-forme embarquée et j'ai besoin d'avoir /dev/fb0 clair pour mon propre usage (l'appareil accessible sur la console série alors que l'écran est utilisé pour afficher des informations, sans X.).
J'ai déjà changé default.target de graphique à multi-utilisateur, mais maintenant il ouvre getty avec une invite de connexion sur le périphérique framebuffer et je ne peux tout simplement pas localiser lequel le service c'est ça. Je ne veux pas désactiver la connexion à la console série par hasard, et lsof ne montre rien avec /dev/fb0 ouvert.
La distribution est Yocto Linux, si cela peut vous aider.
Réponse acceptée :
lsofne montre rien avec/dev/fb0ouvert.
Ce ne sera pas le cas. Il existe un programme d'émulation de terminal intégré au noyau Linux. Il ne se manifeste pas comme un processus en cours d'exécution avec des descripteurs de fichiers ouverts. Il se superpose au framebuffer et au sous-système d'événement d'entrée, auquel il utilise les interfaces internes du noyau pour accéder. Il se présente aux systèmes en mode application comme une série de terminaux virtuels du noyau périphériques, /dev/tty1 et ainsi de suite; un pseudo-fichier sous /sys qui affiche le numéro KVT actif ; et une série de dispositifs de mémoire tampon vidéo de style CGA, /dev/vcsa1 et ainsi de suite.
L'un de ces systèmes en mode application est bien sûr le getty +login système, qui peut être configuré pour fonctionner sur ces terminaux virtuels du noyau, et (comme vous l'avez trouvé) est par défaut. Vous pouvez facilement vous débarrasser du getty processus utilisant des mécanismes systemd documentés.
Dans un ancien System 5 init système, chaque getty serait un enregistrement dans /etc/inittab . Dans un init BSD système, chaque getty est un enregistrement dans /etc/ttys . Dans un système systemd, les choses sont un peu indirectes.
- Le démon "login",
logind, connaît des choses appelées "sièges" dans l'argot systemd. "Seat" zéro est celui avec le framebuffer principal et tous ces terminaux virtuels du noyau. - Pour ce poste,
logindtente de démarrer N services systemd, nommés[email protected]jusqu'à[email protected]N.service. La valeur de N est défini dans lesNAutoVTsparamètre dans/etc/systemd/logind.conf. - Ces services systemd sont créés à partir d'une unité de modèle de service , nommé
[email protected]. Le paramètre de modèle est, comme ci-dessus, le nom de périphérique du fichier de périphérique du terminal virtuel du noyau , dans/dev/. [email protected]est, dans la configuration par défaut, un lien symbolique vers[email protected].- C'est
[email protected]qui décrit l'exécution d'ungettyprogramme, configuré pour effectuer ses entrées/sorties via le fichier de périphérique du terminal virtuel du noyau.
Donc, pour arrêter tout cela, visitez /etc/systemd/logind.conf et configurez logind ne pas démarrer automatiquement tout autovt services (et de ne pas réserver de terminaux virtuels, si vous voulez être minutieux).
Cependant, ce n'est pas tout. Le programme d'émulation de terminal est toujours actif dans le noyau, et tout, des messages de journal dirigés vers un VT du noyau jusqu'au clignotement régulier du curseur, entraînera l'interférence de l'émulateur de terminal avec votre utilisation du framebuffer. Mais c'est une question de codage du programme que vous avez qui utilise le framebuffer pour négocier avec le programme d'émulateur de terminal du noyau, ce qui a déjà été répondu ici.
La connexion à la console série se fait via une route assez différente, soit dit en passant. Un générateur crée une instance de [email protected] unité de modèle une heure de démarrage, en l'instanciant une fois pour chaque périphérique de console du noyau qu'il trouve ou dont il est informé.
Autres lectures
- Meilleure pratique pour masquer la console virtuelle lors du rendu de la vidéo dans le framebuffer
- https://superuser.com/a/723442/38062
logind.conf. pages de manuel systemd. freedesktop.org.- système « multisiège ». freedesktop.org.
systemd-getty-generator. pages de manuel systemd. freedesktop.org.