☰

Otras lecturas

tag-icon • tag-icon getty agetty
Otras lecturas

Tengo un servidor en la nube, con distribución CentOS, y una instancia de Apache para gestionar algunas aplicaciones web, como Wordpress o PrestaShop.

Noté que se informa un error en los archivos de registro ( var/log/).

  • En particular en 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...
  • y en secure: 
    May 30 15:51:30 xxx00962 agetty[24693]: /dev/ttyS0: not a character device

¿Dónde xxx00962está el nombre de host (anónimo)?

No sé para qué sirve getty, pero me gustaría solucionar el problema.

¿Alguien puede ayudarme y explicarme cómo gettyfunciona?

Respuesta1

gettyes uno de los programas Unix más antiguos. Estás utilizando un programa funcional escrito por Wietse Venema, agettyque fue escrito cuando gettytenía unos veinte años.

Este programa se está ejecutando porque su sistema cree que tiene un terminal conectado a un dispositivo serie, con el carácter nombre de archivo del dispositivo /dev/ttyS0. Cuando su sistema se inició, un programa llamado systemd-getty-generatorvio ttyS0en /sys/class/tty/console/active, debido a que aparece después de a console=en la línea de comando del kernel. El generador provocó [email protected]que se creara una instancia de la unidad de servicio de plantilla como [email protected]; y este es el servicio cuyos intentos de activación estás viendo registrados.

El servicio proporciona el inicio de sesión en la terminal a través de ese dispositivo.

Por alguna razón (suponiendo que tenga una versión de systemd de 2014 o posterior), su sistema es inconsistente yahoracree que /dev/ttyS0esnoun archivo de dispositivo de caracteres,sin hablar deun dispositivo de carácter que es una terminal. systemd-getty-generatorPensé que estaba en el arranque. Hay al menos dos formas en las que podría haber cambiado. Su pregunta no puede determinar cuál ha ocurrido, si es que ha ocurrido alguna de las dos cosas.

Arreglar /dev/ttyS0.

  • Si se supone que es un dispositivo de caracteres pero no lo es, descubra qué lo está cambiando en tiempo de ejecución.
  • Si se supone que no es un dispositivo de caracteres, averigüe por qué era un dispositivo terminal en el arranque cuando systemd-getty-generatorlo verificó. También deja de decirle al kernel en su línea de comando que es la consola. Si se supone que no es un dispositivo de caracteres, porque no tiene un puerto serie (con o sin terminal conectado), entonces decirle al kernel que un puerto serie inexistente es la consola es simplemente incorrecto.
  • Si se supone que es un dispositivo de caracteres que es una terminal, pero no desea poder iniciar sesión desde esa terminal, deje de decirle al kernel en su línea de comando que es la consola.
  • Si se supone que es un dispositivo de caracteres que es una terminal, pero quieres que sea la consola del kernel peroaúnSi no desea poder iniciar sesión desde ese terminal (o incluso desde cualquier otra consola que no sea un terminal virtual), desactívelo systemd-getty-generatorporque su funcionalidad principal no es la que desea.

Otras lecturas

Respuesta2

En cualquier sistema Unix, gettyes el nombre tradicional de un proceso que presenta un mensaje de inicio de sesión en una conexión de puerto serie (ya sea una terminal cableada o una línea de módem) y espera a que el usuario inicie sesión.

En un sistema moderno (físico), gettylos procesos normalmente se encuentran proporcionando el mensaje de inicio de sesión en la consola virtual en modo texto. Si el sistema tiene hardware de acceso a la consola remota (como HP iLO, Sun/Oracle ILOM, Fujitsu IRMC u Oracle iDRAC), a menudo proporcionan puertos serie virtuales a los que se puede acceder estableciendo una conexión SSH a través de la interfaz de la consola remota, si el administrador del sistema simplemente configura un gettyproceso para el puerto serie correspondiente.

Esto suele ser mucho más fiable que utilizar una interfaz de consola remota basada en web que utilice Java o HTML5: dado que un puerto serie virtual no tiene que emular el teclado de una PC, no tiene que realizar una asignación inversa de los caracteres entrantes a los códigos de escaneo del teclado y Espero que la distribución del teclado realmente configurada en el sistema operativo del servidor coincida con la que se utilizó para la operación de asignación inversa. Y en el lado de salida, no es necesario intentar extraer la RAM de video para obtener una imagen visualizable.

En las máquinas virtuales, los puertos serie virtuales se pueden usar de la misma manera, por la misma razón: una conexión de puerto serie virtual necesita menos transformaciones en los datos que un "KVM virtual".

En su caso específico, el sistema operativo de la máquina virtual en la nube aparentemente está configurado para esperar un puerto serie virtual como /dev/ttyS0, pero parece que el puerto serie virtual no existe en la VM en este momento. ¿Quizás fue utilizado en el proceso de inicialización de la VM por la infraestructura de la nube?

Probablemente puedas cerrar el gettyproceso en /dev/ttyS0, ya que no parece estar haciendo nada útil en este momento. Para ello, estos comandos podrían ser la solución más sencilla:

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

El primer comando le indica systemdque deje de intentar iniciar el proceso hasta el próximo reinicio, el segundo comando lo marcará persistentemente como deshabilitado.

Hasta que utilice el segundo comando, el primer comando se puede deshacer simplemente reiniciando el sistema. Entonces, si no está seguro, puede usar el primer comando y esperar unos días para ver si causa algún problema. Si descubre que su máquina virtual ahora es inaccesible, un simple reinicio devolvería las cosas a como solían ser.

Comoen la respuesta de JdeBP, también debes verificar tus opciones de arranque: si console=ttyS0aparecen allí, systemdgenerará automáticamente un gettyproceso en /dev/ttyS0.

Respuesta3

Resolví esto editando /etc/systemd/journald.confy configurando

MaxLevelSyslog=warning

información relacionada