☰

进一步阅读

tag-icon • tag-icon getty agetty
进一步阅读

我有一个云服务器，带有 CentOS 发行版，还有一个 Apache 实例来管理一些 Web 应用程序，例如 Wordpress 或 PrestaShop。

我注意到日志文件 ( ) 中报告了错误var/log/。

  • 特别是在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...
  • 并在secure： 
    May 30 15:51:30 xxx00962 agetty[24693]: /dev/ttyS0: not a character device

其中xxx00962是（匿名）主机名。

我不知道有什么getty用，但我想解决这个问题。

有人可以帮助我并解释如何getty工作吗？

答案1

getty是最古老的 Unix 程序之一。您正在使用 Wietse Venema 编写的一个类似的程序，agetty该程序是在getty大约二十岁时编写的。

该程序正在运行，因为您的系统认为您有一个连接到串行设备的终端，其字符设备文件名为/dev/ttyS0。当您的系统引导时，systemd-getty-generator会看到ttyS0一个名为 的程序/sys/class/tty/console/active，因为它列console=在内核命令行中的 a 之后。生成器导致[email protected]模板服务单元被实例化为[email protected]；您看到的就是记录了该服务的尝试激活。

该服务通过该设备提供终端登录。

由于某种原因（假设您有 2014 年或更高版本的 systemd），您的系统不一致，并且现在相信那/dev/ttyS0是不是字符设备文件，更不用说作为终端的字符设备。 systemd-getty-generator认为它处于引导程序。至少有两种方式可以改变它。无法根据您的问题确定发生了哪种情况（如果有）。

使固定/dev/ttyS0。

  • 如果它应该是字符设备，但实际上不是，那么找出运行时是什么改变了它。
  • 如果它不应该是字符设备，请在systemd-getty-generator检查时找出为什么它是引导程序中的终端设备。也不要在命令行上告诉内核它是控制台。如果它不应该是字符设备，因为您没有串行端口（连接或不连接终端），那么告诉内核不存在的串行端口是控制台是完全错误的。
  • 如果它应该是作为终端的字符设备，但您不希望能够从该终端登录，请停止在命令行上告诉内核它是控制台。
  • 如果它应该是一个字符设备，即终端，但您希望它是内核控制台，但仍然不希望能够从该终端（或实际上其他任何其他非虚拟终端控制台）登录，请禁用，systemd-getty-generator因为它的主要功能不是您想要的。

进一步阅读

答案2

在任何 Unix 系统中，getty它是在串行端口连接（硬连线终端或调制解调器线路）上显示登录提示并等待用户登录的进程的传统名称。

在现代（物理）系统中，getty通常会发现进程在文本模式虚拟控制台上提供登录提示。如果系统具有远程控制台访问硬件（例如 HP iLO、Sun/Oracle ILOM、Fujitsu IRMC 或 Oracle iDRAC），它们通常会提供可通过远程控制台界面建立 SSH 连接来访问的虚拟串行端口，如果系统管理员只是getty为对应的串口设置一个进程。

这通常比使用使用 Java 或 HTML5 的基于 Web 的远程控制台界面可靠得多：由于虚拟串行端口不必模拟 PC 键盘，因此它不必将传入字符反向映射回键盘扫描码，并且希望服务器操作系统上实际配置的键盘布局与用于反向映射操作的键盘布局相匹配。在输出端，它不必尝试抓取视频 RAM 来获取可显示的图像。

在虚拟机上，可以以大致相同的方式使用虚拟串行端口，原因也大致相同：虚拟串行端口连接需要比“虚拟 KVM”更少的数据转换。

在您的具体情况下，云虚拟机操作系统显然配置为期望虚拟串行端口为/dev/ttyS0，但看起来虚拟串行端口目前在虚拟机中不存在。也许云基础设施在虚拟机初始化过程中使用了它？

您可以关闭getty上的进程/dev/ttyS0，因为它现在似乎没有做任何有用的事情。为此，这些命令可能是最简单的解决方案：

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

第一个命令告诉systemd停止尝试启动该进程，直到下次重新启动为止，第二个命令将永久地将其标记为禁用。

在使用第二个命令之前，只需重新启动系统即可撤消第一个命令。因此，如果您不确定，您可以只使用第一个命令，然后等待几天，看看它是否会导致任何问题。如果您发现您的虚拟机现在无法访问，只需重新启动即可将一切恢复到原来的状态。

作为在 JdeBP 的回答中，您还应该检查您的启动选项：如果console=ttyS0其中列出，systemd将自动getty在 上生成一个进程/dev/ttyS0。

答案3

我通过编辑/etc/systemd/journald.conf和设置解决了这个问题

MaxLevelSyslog=warning

相关内容