3

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?

3 Answers 3

1

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

4
  • ttyAMA0: It's likely a Raspberry Pi, with one serial port.
    – JdeBP
    Commented Jun 10, 2015 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
    Commented Jun 10, 2015 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
    Commented Jun 10, 2015 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
    Commented Jun 10, 2015 at 21:21
1

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.

1
  • This does not work.
    – Alexandr
    Commented Sep 9, 2023 at 6:18
0

The problem with Tomasz's answer is that, killing the pid of the process that says getty probably won't do anything. If your inittab is set to 'restart' which it usually is with a getty, then even if you do manage to kill it, linux will restart it.

One solution is to comment out the inittab line:

#AMA0:12345:respawn:/bin/start_getty 115200 ttyAMA0 vt102

And then tell the init process to refresh the inittab:

kill -HUP 1

Once this is done, you can kill the correct process with this script:

for pid in $(ls -l /proc/[0-9]*/fd/* | grep /dev/ttyAMA0 | awk '{ print $9 }' | awk -F/ '{ print $3 }'); do
    echo "killing $pid"
    kill -9 $pid
done

The port will now be freed up and you can use it as a serial port.

To simply figure out the pids you need to kill in order to free up the port, you can type:

ls -l /proc/[0-9]*/fd/* | grep /dev/ttyAMA0
1
  • Another way to determine if a port is busy is sudo lsof /dev/ttyAMA0
    – Alexandr
    Commented Sep 9, 2023 at 6:21

You must log in to answer this question.

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