2

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: serial-getty@ttyS0.service 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?

AdminBee
  • 22,803
Round Robin
  • 21

3 Answers3

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 serial-getty@.service template service unit to be instantiated as serial-getty@ttyS0.service; 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

JdeBP
  • 68,745
  • 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 '18 at 11:56
1

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 serial-getty@ttyS0.service
systemctl disable serial-getty@ttyS0.service

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.

telcoM
  • 96,466
  • Hi, I don't understand what is mean "external serial terminal"? It is a terminal phisically connected to a serial port? – Round Robin May 31 '18 at 13:21
  • Stopping the service, I suppose, has not impact to the ssh connection? – Round Robin May 31 '18 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 '18 at 14:09
0

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

MaxLevelSyslog=warning
Stephen Kitt
  • 434,908
user831272
  • 1