I've a cloud server, with CentOS distribution, and an Apache instance to manage some web apps, like Wordpress or PrestaShop.

I noticed that an error is reported in log files (var/log/).

  • In particular in messages:
    May 30 11:54:41 xxx00962 systemd: Starting Serial Getty on ttyS0...
    May 30 11:54:41 xxx00962 systemd: Started Serial Getty on ttyS0.
    May 30 11:54:51 xxx00962 systemd: [email protected] holdoff time over, scheduling restart.
    May 30 11:54:51 xxx00962 systemd: Stopping Serial Getty on ttyS0...
  • and in secure:
    May 30 15:51:30 xxx00962 agetty[24693]: /dev/ttyS0: not a character device

where xxx00962 is the (anonymized) hostname.

I don't know what is getty for, but I'd like to solve the problem.

Someone can help me and explain how getty works?

3 Answers 3


getty is one of the oldest Unix programs. You are using a workalike program written by Wietse Venema, agetty, that was written when getty was around twenty years old.

This program is being run because your system thinks that you have a terminal attached to a serial device, with the character device filename /dev/ttyS0. When your system bootstrapped, a program named systemd-getty-generator saw ttyS0 in /sys/class/tty/console/active, because of it being listed after a console= in the kernel command line. The generator caused the [email protected] template service unit to be instantiated as [email protected]; and this is the service whose attempted activations you are seeing being logged.

The service provides terminal log-on via that device.

For some reason (presuming that you have a version of systemd from 2014 or later), your system is inconsistent, and now believes that /dev/ttyS0 is not a character device file, let alone a character device that is a terminal. systemd-getty-generator thought that it was at bootstrap. There are at least two ways in which it could have changed. Which, if either, has occurred cannot be determined from your question.

Fix /dev/ttyS0.

  • If it is supposed to be a character device but isn't, then find out what is changing it at runtime.
  • If it is not supposed to be a character device, find out why it was a terminal device at bootstrap when systemd-getty-generator checked it. Also stop telling the kernel on its command line that it is the console. If it is not supposed to be a character device, because you do not have a serial port (with terminal attached or without), then telling the kernel that a non-existent serial port is the console is simply wrong.
  • If it is supposed to be a character device that is a terminal, but you do not want to be able to log on from that terminal, stop telling the kernel on its command line that it is the console.
  • If it is supposed to be a character device that is a terminal, but you want it to be the kernel console but still do not want to be able to log on from that terminal (or indeed other any other non-virtual-terminal consoles), disable systemd-getty-generator because its primary functionality is not what you want.

Further reading

  • Great answer! But since I was already pretty much written mine in a slightly different angle, I'll went on to post mine too.
    – telcoM
    May 31, 2018 at 11:56

In any Unix system, getty is the traditional name for a process that presents a login prompt on a serial port connection (either a hardwired terminal or a modem line) and waits for user to log in.

In a modern (physical) system, getty processes are normally found providing the login prompt on the text-mode virtual console(s). If the system has remote console access hardware (like HP iLO, Sun/Oracle ILOM, Fujitsu IRMC or Oracle iDRAC), they often provide virtual serial ports that are accessible by establishing a SSH connection through the remote console interface, if the system administrator just sets up a getty process for the corresponding serial port.

This is often much more reliable than using a web-based remote console interface that uses Java or HTML5: since a virtual serial port does not have to emulate a PC keyboard, it does not have to reverse-map incoming characters back into keyboard scancodes and hope that the keyboard layout actually configured on the server OS matches what was used for the reverse-mapping operation. And on the output side, it does not have to attempt to scrape the video RAM for a displayable image.

On virtual machines, virtual serial ports can be used much the same way, for much the same reason: a virtual serial port connection needs less transformations on the data than a "virtual KVM".

In your specific case, the cloud virtual machine OS is apparently configured to expect a virtual serial port as /dev/ttyS0, but it looks like the virtual serial port does not exist in the VM right now. Perhaps it was used in the VM initialization process by the cloud infrastructure?

You can probably shut down the getty process on /dev/ttyS0, as it does not seem to be doing anything useful right now. To do that, these commands might be the simplest solution:

systemctl stop [email protected]
systemctl disable [email protected]

The first command tells systemd to stop trying to start the process until the next reboot, the second command will persistently mark it as disabled.

Until you use the second command, the first command can be undone simply by rebooting the system. So if you're uncertain, you can just use the first command and wait a few days to see if it causes any problems. If you find your VM is now unreachable, a simple reboot would return things to what they used to be.

As in JdeBP's answer, you should also check your boot options: if console=ttyS0 is listed in there, systemd will automatically generate a getty process on /dev/ttyS0.

  • Hi, I don't understand what is mean "external serial terminal"? It is a terminal phisically connected to a serial port? May 31, 2018 at 13:21
  • Stopping the service, I suppose, has not impact to the ssh connection? May 31, 2018 at 13:22
  • Regarding external serial terminal - yes, once long ago it was just that; then PCs with terminal emulator software replaced the physical terminals, and various ways were added to extend the connection into network, beyond physical serial cables and modem lines. And since the getty process is producing errors now, it should definitely not impact the SSH connection in any way.
    – telcoM
    May 31, 2018 at 14:09

I solved this by editing /etc/systemd/journald.conf and setting


You must log in to answer this question.

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