I have two computers that both have a RS-232 port on /dev/ttyS0 connect together with a null modem.

I am trying to understand bit by bit how an external terminal worked in the old days, and how that relates to how linux works today.

I have gotten it to work like this:

main computer:

$ sudo socat /dev/ttyS0,raw,echo=0 exec:"/bin/bash -i",pty,stderr,setsid,sigint,sane


picocom -b 9600 /dev/ttyS0

However, that has pty in it - which is why I get this on the terminal:

# tty

and you shouldn't need a pseudo tty if you have an actual real life tty should you? I mean they were connecting terminals in with wires before they had pseudo anything weren't they?

So I have been trying to mix and match socat options to make it with with no pty, but with no luck. If I can anything appears in my terminal computer, there are no carriage returns or job control and tty says "not a tty".

I have to admit I don't understand the socat syntax (or terminal settings) - I was hoping to see the correct answer, and understand the syntax from there.

Could somebody either tell me how to make a remote terminal with no pty, or help me accept that it's not possible?

  • You fired your command under some Xterm didn't you ? Do you get means to access the system console and retry your experiments ?
    – MC68020
    Oct 4, 2023 at 8:29
  • you mean like - ctrl+alt+Fx?
    – Alex028502
    Oct 4, 2023 at 8:31
  • 1
    You could start the tty with getty. something like getty -8 9600 ttyS0 should do.
    – stoney
    Oct 4, 2023 at 8:35
  • @Alex028502 : Yes indeed ! And from there… can't you forget everything about ptys ?
    – MC68020
    Oct 4, 2023 at 8:53
  • @MC68020 yeah - I tried that - I actually tried it by swapping the computers, since the "terminal" is arch linux with no gui... and I got the same message - so I know it's not my computer
    – Alex028502
    Oct 4, 2023 at 13:41

1 Answer 1


If you start getty from the command line, you might need to run it as root and wrap it into a loop:

while true; do getty -8 9600 ttyS0; done

One invocation of getty gives you just one session, or a set of usually 3 login attempts, or until the serial port gets a hang-up signal. If picocom sends a hang-up initially to reset the serial line, it would cause the first getty to exit.

If a getty process is not terminated early by a serial port hang-up signal, then it will set up the TTY device, send the contents of /etc/issue to the terminal, and then present a login prompt. If a valid username is entered, getty will exec() (note: without fork()ing first) /bin/login, which will usually invoke the PAM libraries to handle the password prompt and the rest of the user session set-up. As part of that procedure, the identity of the process will be switched to the user that is logging in, and then the process that started as getty and then turned into login will again call exec() to become the user's shell. If that process dies for any reason, the user's session will end, and a new getty process will be started for a new login.

Running a getty manually in a loop might be a good way to "visualize" what needs to be happening, but it is not the proper way for long-term use.

All the getty processes are really intended to be started by init and restarted whenever the process that started its life as getty (and gets transformed into the user's shell on a successful login) dies... so on a modern Linux distribution that uses systemd, the command to make a getty run on a serial port connected to a terminal is usually:

systemctl start [email protected]

To make it persist over reboots, you'll also need a

systemctl enable [email protected]

If you are using classic SysVinit instead, there should be commented-out example lines in /etc/inittab file: just uncomment the appropriate line, then run telinit q to make SysVinit re-read its configuration, and init should immediately start a getty process for the terminal and keep restarting it as necessary.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .