дальнейшее чтение

дальнейшее чтение

У меня есть облачный сервер с дистрибутивом CentOS и экземпляр Apache для управления некоторыми веб-приложениями, такими как 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=в командной строке ядра. Генератор вызвал [email protected]создание экземпляра шаблонного сервисного модуля как [email protected]; и это служба, попытки активации которой вы видите в журнале.

Сервис обеспечивает терминальный вход в систему через это устройство.

По какой-то причине (предполагается, что у вас версия systemd 2014 года или более поздняя) ваша система несовместима, исейчассчитает, что /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: поскольку виртуальный последовательный порт не должен эмулировать клавиатуру ПК, ему не нужно обратно отображать входящие символы в скан-коды клавиатуры и надеяться, что раскладка клавиатуры, фактически настроенная на серверной ОС, соответствует той, которая использовалась для операции обратного отображения. А на стороне вывода ему не нужно пытаться очистить видеопамять для отображаемого изображения.

На виртуальных машинах виртуальные последовательные порты можно использовать примерно таким же образом и по той же причине: подключение через виртуальный последовательный порт требует меньше преобразований данных, чем «виртуальный 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

Связанный контент