0

My apologies if this is a ultra basic question:

Does linux / systemd / agetty support double ended serial-getty consoles?

For example I have two remote servers A and B, they are running a recent ubuntu with systemd, agetty and screen installed. There is a null modem cable installed bewteen the servers and it appears on /dev/ttyS0 on both.

From Server B I can use screen to get a login prompt (agetty) on server A.

From that prompt I can reboot the server A, grub comes up I can make choices in grub, boot Linux, I see the boot messages, then a successful login prompt etc all over a serial link from B.

Is it possible to do the reverse with the same serial port/link ? Can I use screen to login to server B from A over the same /dev/ttyS0? Can server B also have agetty listen on /dev/ttyS0 when it is not in use by screen?

And if not and I need a second serial port/cable to get from A -> B, is that a hardware limitation of UART or a software limitation of agetty or systemd ? And if its a systemd issue it this possible in a non-systemd Linux say Gentoo?

Thank you in advance.

turtle
  • 176
  • 8
  • Consoles has own internal status (in your case directly on Linux kernel). and IN/OUT on console use different "protocols/translation", so it is easy to get both confused, but if you force a very simple terminal type and you force not to change any settings. So you may need to program a program which filter (and dispatch) data. Or keep it just as "printer" (display output, but not the complex terminal part) – Giacomo Catenazzi Jun 09 '23 at 09:23

1 Answers1

0

Bidirectional communication is possible over a serial line, so you can arrange to run multiple sessions over one. You'll need some protocol for multiplexing them, possibly something like PPP that makes the serial line act as a network connection.

Without multiplexing, consider what happens if both sides print a prompt and expect a command in response (be it a shell prompt or a login prompt). Side A prints a prompt, and expects to read a command; side B prints a prompt; side A reads the prompt from B... and processes it as a command. That won't work.

In the least you'd need some arrangement to agree which side should act as the host for a session. E.g. start both sides in a passive mode, waiting for the other to send a command to request a session. Then launch the login process on the host and a terminal client on the client side. At the end of the session, return to the neutral state to be ready for a new session (in either direction).

ilkkachu
  • 133,243
  • 15
  • 236
  • 397
  • 4
    When I was a support tech at a modem company widely used on Unix computers, this was a config that wasn't used much, but I did run into it from time to time. The trick was to configure the two gettys to open the tty port, but not lock it or issue a login prompt. Just silently listen for incoming characters without echoing them. When one is received, lock the port, enable echo, write the prompt, and continue normally. If the lock fails, an outbound terminal program has the port, so getty just sleeps. It was tricky but possible with many Unix gettys. Alas I don't recall the config anymore. – Sotto Voce Jun 08 '23 at 23:17
  • @SottoVoce thank you for the info. If you do happen to recall the config please do add a comment here. – turtle Jun 09 '23 at 19:29