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?


(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.

  • ttyAMA0: It's likely a Raspberry Pi, with one serial port. – JdeBP Jun 10 '15 at 10:45
  • Thank you. As for the infinite loop, I don't mind too much in theory. Timeouts and such will prevent it from consuming too much resources. I don't have spare serial ports, though. @JdeBP is correct, these are Raspberry Pis, and I'm looking to have about 60 of them, and I really don't want to buy 120 USB adapters for this purpose. – PythonNut Jun 10 '15 at 14:22
  • Fair enough. I guess if luck has it such that the chatting does not occur or is not too bad, it can work as a compromise. – Celada Jun 10 '15 at 15:10
  • 1
    @Celada thankfully, my usernames do not contain the passwords to the opposite machines. :) I'll test it as soon as I can, but I'm having some other difficulties, so it may take a while. Oh, and the GeTTY think is a bad habit from using PuTTY. – PythonNut Jun 10 '15 at 21:21

You can send a stop signal. It won't restart until r or another signal is sent.

sudo kill -19 <pidOfGetty>

You can check if it is currently stopped with:

ps a | grep getty

root       948  0.0  0.0   4656  2032 tty5     Ts+  Sep20   0:00 /sbin/getty -8 38400 tty5
root       958  0.0  0.0   4656  1880 tty2     Ss+  Sep20   0:00 /sbin/getty -8 38400 tty2

Process state code T means it is stopped. Like in process 948 on tty5.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.