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