getty hängt sich auf und vereitelt Shutdown

[generalmajor]

Moin,

hier leider ein etwas vertrackter Fall: Ich habe an meinem Arbeits-PC noch ein altes serielles Terminal (VT420) am RS232-Port (ttyS4) hängen. Seit längerer Zeit bekomme ich keinen Login mehr dafür. Bildschirm bleibt leer. Ein Test mit Minicom verläuft allerdings positiv. Baudrate etc. habe ich auch gecheckt und statt agetty den mgetty probiert. Immer passiert aber Folgendes: Der jeweilige Getty-Prozess wird zwar gestartet, arbeitet aber nicht und lässt sich mit

systemctl stop serial-getty@ttyS4

nicht beenden. Der Befehl hängt sich auf, und das war's. Den Prozess killen kann ich auch nicht. Und noch schlimmer: Fahre ich den Rechner herunter, hängt er sich zum Schluss auch auf, und ich muss ihn per Ein-/Aus-Schalter schlafen legen. Nehme ich den Symlink

/etc/systemd/system/getty.target.wants/serial-getty@ttyS4.service -> /usr/lib/systemd/system/serial-getty@.service

raus, fährt das System wieder normal herunter. Terminal an einen anderen Anschluss anstecken und den Getty entsprechend umkonfigurieren hilft übrigens nicht.

Beim Hochfahren bemerke ich, dass komische Zeichen auf dem Bildschirm des Terminals erscheinen:

þþÿ

Ein paar Sekunden später kommen noch weitere Zeichen dazu. Genau die gleichen Hieroglyphen bekomme ich, wenn ich den ModemManager neu starte. Kommt er etwa dem Getty in die Quere?! :/ Ich habe ihn zwar schon aus der systemd-Config herausgenommen, doch erscheinen die gleichen Zeichen immer noch auf dem Schirm. Da würde ich gerne wissen, wie ich ihn effektiv von den RS232-Ports fernhalte.

Danke für jeden zielführenden Tipp!

UPDATE: Beim Systemstart erscheint sehr wohl der Anmeldebildschirm aus /etc/issue, doch ein paar Sekunden später tauchen o.a. Hieroglyphen wieder auf, und ab dem Zeitpunkt geht nix mehr. Nicht mal die Symlinks kann ich löschen oder die verklemmten Getty-Prozesse killen. Nix!

 

[longman]

ich gestehe, es ist nur eine Vermutung.

Aber ich würde den Fehler trotz erfolgreichen minicom Tests im Bereich Hardware Terminal, Kabel oder Schnittstelle suchen (Interrupt, Parity, Bios Setting, PnP, usw.)
Schonmal ne andere IO Karte versucht ?

 

[generalmajor]

Das VT420 hat schon Jahre lang gefunzt, doch erst seit nicht mal einem Jahr (da war ein System-Upgrade auf 13.2, kann ich mich ganz dunkel erinnern) funzt es nicht mehr. Gerade habe ich es mit ttyS0 probiert. Dieser Anschluss ist onboard. Erste Tests verliefen positiv (keine Hieroglyphen, dafür Startbildschirm), doch mittlerweile komme ich auch hier nicht mehr weiter. Auch das Stoppen mit systemctl klappt nicht (hängt sich auf). Noch schlimmer: Danach gehen auch keine Logins direkt am System (Bildschirm entsperren, virtuelles Terminal, su/sudo auf Konsolenprogramm). Der Login-Prozess hängt sich dann einfach auf!

Funkt hier vielleicht der ModemManager dazwischen?

 

[spoensche]

Auch das Stoppen mit systemctl klappt nicht (hängt sich auf). Noch schlimmer: Danach gehen auch keine Logins direkt am System (Bildschirm entsperren, virtuelles Terminal, su/sudo auf Konsolenprogramm). Der Login-Prozess hängt sich dann einfach auf!
Funkt hier vielleicht der ModemManager dazwischen?

Der ModemManager hat nichts mit dem Terminal am Hut und haut auch nicht dazwischen.

Es passiert folgendes:

ttyS4 funktioniert wie es soll. Es wird neben tty1 als weitere Konsole verwendet, über die auch Anmeldungen am System möglich sind. Daraus ergibt sich logischerweise, dass man das Terminal nicht manuell stopt. Du stopst den Displaymanager bzw. X-Server, der auf tty7 läuft auch nicht manuell, sondern lässt ihn ordnungsgemäß vom System selbst herunterfahren.

Da auf ttyS4 keine explizite Anwendung läuft die den Login ans System weiterreicht (z.B. wie der X- Server den Input handelt) ist ttyS4 eine Konsole wie tty1 -ttyX auch. Wenn du das ganze jetzt manuell stopst, ist die logische Konsequenz, das gleiche Verhalten wie bei tty1. Folglich ver
hält sich das System so, als wenn du manuell tty1 abschießt.

Zu den Hyroglyphen:

Die Buadrate ist zu hoch. Für ttyS4 dürfte 57200 Baud eingestellt sein, nur dein Terminal arbeitet mit 38400 Baud.

 

[generalmajor]

Dann ist das Nicht-beenden-Können also ein Feature und kein Bug.

Nach falscher Baudrate sieht's aber (zumindest, was die Config angeht) nicht aus. Hier der Inhalt von serial-getty@.service:

[Unit]
Description=Serial Getty on %I
Documentation=man:mgetty(8) man:systemd-getty-generator(8)
Documentation=http://0pointer.de/blog/projects/serial-console.html
BindsTo=dev-%i.device
Conflicts=rescue.service
After=dev-%i.device systemd-user-sessions.service plymouth-quit-wait.service
After=rc-local.service

# If additional gettys are spawned during boot then we should make
# sure that this is synchronized before getty.target, even though
# getty.target didn't actually pull it in.
Before=getty.target
IgnoreOnIsolate=yes

[Service]
# ExecStart=-/sbin/agetty --keep-baud %I 115200,38400,9600 $TERM
ExecStart=-/usr/sbin/mgetty -rs 19200 -i /etc/issue.mgetty %I
# ExecStopPost=-/sbin/vhangup /dev/%I
Type=idle
Restart=always
UtmpIdentifier=%I
TTYPath=/dev/%I
TTYReset=yes
TTYVHangup=yes
KillMode=process
IgnoreSIGPIPE=no
SendSIGHUP=yes

[Install]
WantedBy=getty.target

Und das VT ist so eingestellt:

Senden=19200; Empfang=Senden; Xoff bei 128; 8 Bit, keine Parität; 1 Stoppbit; Fernecho; Nullmodem; Abfallzeit 2 s

 

[spoensche]

Dann ist das Nicht-beenden-Können also ein Feature und kein Bug.

Laut der systemd Konfig eher ein Konfigurationsfehler, weil du mit

Restart=always

sagst, dass er immer neu gestartet werden soll. Daher kannst du dieses TTY auch nicht beenden.

 

[generalmajor]

Andersrum: Ich wünsche mir, dass der getty immer, wenn ich mich am Terminal abmelde, einen neuen Login-Schirm präsentiert. Was ich jedoch nicht will, ist, dass sich gleich der ganze tty-Port verklemmt.

 

[generalmajor]

UPDATE: Hab gerade das Restart=always und dazu TTYVHangup=yes auskommentiert und es nochmal probiert. Ergebnis: Der erste Login geht klaglos, doch melde ich mich vom Terminal ab, passiert nichts mehr. Sogar der Versuch, den Status von getty zu überprüfen, schlägt mit einer mysteriösen Meldung fehl:

jacek@veteran:/etc/systemd/system/getty.target.wants $ systemctl status serial-getty@ttyS0.service
Failed to get properties: Die Wartezeit für die Verbindung ist abgelaufen

 

[spoensche]

Entferne mal den Kommentar vor Restart=always

 

[generalmajor]

Auch schon probiert. No use.

 

[spoensche]

Was machenden bitte das in der Service- Konfiguration?

Conflicts=rescue.service
After=rc-local.service

Beim Initvorgang wird rc.local als aller letztes in jedem Runlevel ausgeführt, also dann wenn z.B. die Netzwerkverbindung konfiguriert ist oder X-Server schon gestartet ist.

Wenn du dich jetzt abmeldest kann das System überhaupt keine Attribute des Terminals bekommen, weil es ja erst nach rc.local ausgeführt werden soll, aber nach einem Logout werden keinerlei Initscripts ausgeführt, die zum Starten eines Dienstes o.ä. vorgesehen sind. Folglich wartet dein System vergeblich auf Infos vom Terminal, die es nicht empfangen kann, weil kein rc.local gestartet wurde.

Beispiel:

Du hast dein Auto auf nem Parkplatz geparkt und die Handbremse (Serieles Terminal) angezogen (System gebootet), jetzt komit amst du vom Kaffetrinken wieder zu deinem Auto steigst ein und fährst mit angezogener Handbremse los, die du nicht lösen kannst, weil sie sich beim anziehen (Logout) aufgehängt hat. Foglich stehst du auf dem Parkplatz und kommst keinen Meter voran.

 

[generalmajor]

Ehrlich gesagt, habe ich die Vorlage serial-getty@.service einfach nur angepasst (Port-ID, Baudrate, Getty-Programm). Was ganz besonders die letzte Zeile zu bedeuten hat, erschließt sich mir erst durch Deine Ausführungen. :mute: Kann durchaus sein, dass sie in früheren Versionen des Files gefehlt haben. Aber OK, ist kommentiere beide Zeilen erst mal aus und probiere es nochmal.

Scheint aber nicht zu helfen! Eine Session kriege ich auf dem Terminal noch hin, doch logge ich mich dort aus, kommt nur ein abgebissenes «Abg», doch eine neue Session kommt nicht mehr. Eine neue Session kann ich nicht mehr initiieren, weil offenbar der Service verklemmt ist. Sogar ein erneutes Einlesen der Config geht dann nicht mehr:

veteran:/etc/systemd/system/getty.target.wants # systemctl daemon-reload
Failed to execute operation: Connection timed out

In meiner rc-local.service steht übrigens das da:

[Unit]
Description=/etc/init.d/boot.local Compatibility
ConditionFileIsExecutable=/etc/init.d/boot.local
After=basic.target

[Service]
Type=forking
ExecStart=/etc/init.d/boot.local start
TimeoutSec=0
RemainAfterExit=yes
SysVStartPriority=99

 

[generalmajor]

Den Fall möchte ich nochmal an die Oberfläche bringen: Ich habe es nämlich mit einem RS232-auf-USB-Adapter von CSL und der Schnittstelle /dev/ttyUSB0 probiert. Leider hatte ich auch hiermit keinen Erfolg: Die erste Session arbeitet noch zuverlässig, doch beim Abmelden kommt exakt das gleiche Symptom wie bei direktem Anschluss an einen RS232-Port: Es kommt ein abgehacktes «Abg», dann drei øøø und dann nichts mehr. Vom serial-getty@ttyUSB0.service lässt sich nicht mal mehr der Status abrufen, das Config-File serial-getty@.service nicht mal lesend öffnen. Der gleiche Deadlock wie vorher also. Es ist also auch nicht die Schnittstellen-HW.

Hier der letzte Stand des Config-Files:

[Unit]
Description=Serial Getty on %I
Documentation=man:mgetty(8) man:systemd-getty-generator(8)
Documentation=http://0pointer.de/blog/projects/serial-console.html
BindsTo=dev-%i.device
# Conflicts=rescue.service
After=dev-%i.device systemd-user-sessions.service plymouth-quit-wait.service
# After=rc-local.service

Before=getty.target
IgnoreOnIsolate=yes

[Service]
# ExecStart=-/sbin/agetty --keep-baud %I 115200,38400,9600 $TERM
ExecStart=-/usr/sbin/mgetty -rs 19200 -i /etc/issue.mgetty %I
ExecStopPost=-/sbin/vhangup /dev/%I
Type=idle
Restart=always
UtmpIdentifier=%I
TTYPath=/dev/%I
TTYReset=yes
TTYVHangup=yes
KillMode=process
IgnoreSIGPIPE=no
SendSIGHUP=yes
SyslogLevel=warning

[Install]
WantedBy=getty.target