I have machines in pairs. They're connected to each other by a null modem serial cable. These machines sometimes go down, and the only way to diagnose them is through that cable, using the other node of the pair.These devices have Getty configured to run on the serial device /dev/ttyAMA0. This is by default, and I'd like to keep as close to the default config as possible.Here's the problem:I can't seem to get Getty to relinquish control of the device, so I can use something like minicom to log into the other device. Unfortunately, simply killing getty doesn't work, as something seems to immediately restarts it.How can I get getty to stop?
How to free a serial port owned by Getty
linux;serial port;serial console;getty
(By the way, I've never seen the spelling GeTTY. I don't think it's correct.)The short answer is that you can disable getty by commenting it out in /etc/inittab and running init q to reread configuration. Unless you're using systemd or Upstart but since you didn't say so I'll assume you aren't.The longer answer is that your setup has an intrinsic problem and is flawed. With getty running on both serial ports, the two getty processes run the risk of starting to endlessly chat with each other. That is, one will send a prompt, which the other one interprets as a username, which causes it to produce its own prompt, which gets interpreted as a username on the original end, and so on forever.The correct way to handle this is to use two serial ports, one in each direction. The console serial port on system 1 is connected to the extra serial port on system 2, and the console serial port on system 2 is connected to the extra serial port on system 1. Since the extra serial ports on both systems never run getty (only the console serial ports do), there is never a getty to disable, and the port can be directly used by screen or cu etc...For the extra serial ports, you can use USB serial port adaptors if the systems do not provide enough built-in serial ports. Because those ports are only accessed after the system is fully booted (unlike the console serial port) it's OK for them to be on a USB bus which will not be initialized until partway through the boot sequence.