OVH Community, your new community space.

TTY1 y TTY2 bucle log messages. [CentOS 6.5) [Problema OVH]


Deskit
29/05/2014, 21:42
Exacto Samael,

Salvo los de Madrid que hay que decirlo tienen un horario limitado, pero cumplen con ello, pero los demás los que consideran administradores de sistemas y que son los responsables, haciendo este tipo de cosas y lo que tu comentas, es que muy administradores no son.

Eso si, decir que cambie de distribución, como si de una estación de trabajo recien instalada se tratase, pues la verdad, ahora llamarán administradores de sistemas a quien instalan un Windows en su escritorio.

Es que no sé que se creen, que cambien de distro en OVH a ver si les hace gracia, seguro que en su server OVH, hacen pruebas antes de hacer algo en producción (Imagino), pero estoy viendo que el soporte a nivel de administración deja mucho que desear (No los de Madrid) sino los que están considerados administradores de sistemas, que de administradores tienen lo que yo de cura, pero bueno, a todo se le puede llamar administrador de sistemas hoy en día.

Ahora me ha respondido rápido, pero es que...

Dear customer,

Thank for your reply. And thanks for the effort that you
have made to enrich OVH forum.

Best regards,

Gracias y saludos, espero que esto vaya mejorando, que visto lo visto y también lo que me has contado, espero que tengamos suerte.

Samael
29/05/2014, 20:21
En OVH TODO es BETA muy lamentable, pero así es.
Recientemente cambiaron de panel y el que pusieron tiene errores, errores que reporte hace meses, pero que no los repararon y pusieron igual en producción, si no sabes lo que haces elegir OVH es suicidarse.

Deskit
29/05/2014, 20:09
Bueno, tengo que ponerlo porque hay que decir la verdad,

No voy a poner nombres por temas eticos y por seguridad, pero tengo que decir que los del soporte técnico de Madrid, cumplen con su horario y nunca han dejado de contestar, es más, se han ofrecido para enviarme el ticket, a los que se supone que son administradores de sistemas.

La respuesta que he recibido es la siguiente:

Dear customer,

The issue that you report might be caused by a kernel bug.
Anyway, I recommend you to try to change your distribution.

Best regards,

Y mi email:

Buenas tardes,

¿Que cambie de distribución? Esto es como si digo que cambie de distribución OVH teniendo datos en el servidor. ¿Tengo que estar así siempre?

A ver, la otra vez me comentaron de que el error podria ser de mis aplicaciones, (Descartado totalmente). Ahora me dicen que puede ser un error causado por el kernel.

Ustedes, ¿Realmente utilizan los servidores contratados como servidores de pruebas? ¿No tienen servidores virtuales para implantarlos antes y luego pasarlo a producción?

He estado trabajando en empresas grandes como administrador de sistemas de tercer nivel y siempre antes de poner en producción los sistemas, hemos hecho pruebas piloto en servidores virtuales, luego una vez analizados se pasa a producción.

Esto es lamentable, que se utilicen los servidores virtuales contratados como servidores de prueba.

Cuando un servidor no tiene este bug aparece lo siguiente en el apartado TTY lo hago desde otro server mio

root 1470 0.0 0.0 4064 556 tty1 Ss+ 19:05 0:00 /sbin/mingetty /dev/tty1
root 1472 0.0 0.0 4064 560 tty2 Ss+ 19:05 0:00 /sbin/mingetty /dev/tty2
root 1474 0.0 0.0 4064 560 tty3 Ss+ 19:05 0:00 /sbin/mingetty /dev/tty3
root 1476 0.0 0.0 4064 556 tty4 Ss+ 19:05 0:00 /sbin/mingetty /dev/tty4
root 1478 0.0 0.0 4064 556 tty5 Ss+ 19:05 0:00 /sbin/mingetty /dev/tty5
root 1480 0.0 0.0 4064 560 tty6 Ss+ 19:05 0:00 /sbin/mingetty /dev/tty6

Cuando se tiene el problema de ahora, hay dos conflictos

/sbin/mingetty /dev/tty1
/sbin/mingetty /dev/tty2

Puesto que si hacemos un $ ps aux sucede lo siguiente

root 871 0.0 0.0 4064 652 ? Ss 19:35 0:00 /sbin/mingetty /dev/tty1
root 872 0.0 0.0 4064 652 ? Ss 19:35 0:00 /sbin/mingetty /dev/tty2

Aparece un ? en TTY cuando realmente hay otro TTY1 y TTY2

root 735 0.0 0.0 4068 556 tty1 Ss+ 19:34 0:00 /sbin/mingetty console
root 736 0.0 0.0 4068 556 tty2 Ss+ 19:34 0:00 /sbin/mingetty tty2

Por eso hace el bucle que genera en el log messages por un conflicto que tiene preferencia console como TTY1 y TTY2

Por favor, no digan una cosa y luego otra.

Gracias por lo de cambiar de distro, pero ya he puesto en el foro la solución al problema.

Gracias de nuevo.

Reciba un cordial saludo.

Hay que tener en cuenta que se tiene que hacer una prueba piloto antes de implantar en servidores en producción, sean baratos o caros, no dejamos de ser clientes y eso demuestra seriedad, pero da muestras de que descubren las cosas mediante la marcha y eso al menos en este mundo no es así.

Mis felicitaciones por el soporte que recibo desde Madrid, pero los que se supone que son administradores de sistemas me da la espina que son becarios disfrazados de administradores.

Lamento este mensaje, pero las verdad, es verdad y lo que no es, no es.

Deskit
28/05/2014, 06:16
Bueno me contesto yo mismo, ya que es un problema de OVH con las TTY y lo he tenido que resolver, porque no se enteran. Ya podría contratar el Sr. Klaba Octave alguien como yo.

Parece ser que utilizan una terminal y esa es TTY1 y TTY2 puesto que de otra forma no se explica y lo dejan en proceso y va realizando un bucle en el log que en dos dias tienes 50 MB de log.

Para solucionarlo hay que ir al path /etc/init y en el fichero start-ttys.conf escribir en la shell lo siguiente:

$ cp -p start-ttys.conf start-ttys.conf.override

$ cat start-ttys.conf.override

#
# This service starts the configured number of gettys.
#
# Do not edit this file directly. If you want to change the behaviour,
# please create a file start-ttys.override and put your changes there.

start on stopped rc RUNLEVEL=[2345]

env ACTIVE_CONSOLES=/dev/tty[1-6]
env X_TTY=/dev/tty1
task
script
. /etc/sysconfig/init
for tty in $(echo $ACTIVE_CONSOLES) ; do
[ "$RUNLEVEL" = "5" -a "$tty" = "$X_TTY" ] && continue
initctl start tty TTY=$tty
done
end script

$ vi start-ttys.conf.override

Hay que modificar la línea "env ACTIVE_CONSOLES=/dev/tty[1-6]" cambiar el 1 por el 3 quedaria así [3-6]

Guardar los cambios.

Ir al path /etc/sysconfig/

$ cat init

# color => new RH6.0 bootup
# verbose => old-style bootup
# anything else => new style bootup without ANSI colors or positioning
BOOTUP=color
# column to start "[ OK ]" label in
RES_COL=60
# terminal sequence to move to that column. You could change this
# to something like "tput hpa ${RES_COL}" if your terminal supports it
MOVE_TO_COL="echo -en \\033[${RES_COL}G"
# terminal sequence to set color to a 'success' color (currently: green)
SETCOLOR_SUCCESS="echo -en \\033[0;32m"
# terminal sequence to set color to a 'failure' color (currently: red)
SETCOLOR_FAILURE="echo -en \\033[0;31m"
# terminal sequence to set color to a 'warning' color (currently: yellow)
SETCOLOR_WARNING="echo -en \\033[0;33m"
# terminal sequence to reset to the default color.
SETCOLOR_NORMAL="echo -en \\033[0;39m"
# Set to anything other than 'no' to allow hotkey interactive startup...
PROMPT=yes
# Set to 'yes' to allow probing for devices with swap signatures
AUTOSWAP=no
# What ttys should gettys be started on?
#ACTIVE_CONSOLES=/dev/tty[1-6]
ACTIVE_CONSOLES=/dev/tty[3-6]
# Set to '/sbin/sulogin' to prompt for password on single-user mode
# Set to '/sbin/sushell' otherwise
SINGLE=/sbin/sushell

Como podeis ver la linea ACTIVE_CONSOLES=/dev/tty[1-6] esta comentada

Se modifica y quedaria así "ACTIVE_CONSOLES=/dev/tty[3-6]"

Se reinicia el server

Hacer un ps aux y vereis como tty1 y tty2 no aparecen, queda desactivado

Y si alguien quiere entrar por KVM por IP iniciará con /dev/console

Para mayor seguridad y si no quereis que entren con usuario root podeis comentar tty1 y tty2 en /etc/securetty

OVH tomar nota, porque el personal cuando envias un ticket te responden a los 15 dias, no se enteran, siendo vosotros los responsables del fallo, que en ningún momento ni hay intrusión en mi server ni nada, que es muy fácil quitarse la culpa de encima, cuando no sabéis ni de que viene el fallo.

Siento mi enfado, pero es que el soporte es nulo, pero malo, malo, a mas no poder.

Saludos a todos.

Deskit
28/05/2014, 03:02
Buenas a todos.

Soy cliente de OVH, y como veo que enviando un ticket no han sabido resolverme el problema, aquí dejo mi mensaje para ver si hay alguien competente y me puede echar una mano.

Me cambiaron el kernel el 14 de Mayo de 2014 en mi VPS contratado a la versión 2.6.32-042stab088.4, en los demás servidores tengo una versión anterior del kernel que es la 2.6.32-042stab084.14 (No lo han actualizado) y no tengo problemas con la misma configuración, tampoco tenia problemas, con el server que les voy a comentar, y es lo siguiente:

Envío el mismo día 14 de Mayo un ticket y me responden el Martes 20 de Mayo de 2014, diciendome en inglés que no pueden hacer nada y que mire las aplicaciones. (Más abajo explico que hice con el ticket).

En /var/log/messages me aparece:

May 23 04:16:40 x01 /sbin/mingetty[2966]: tty1: no controlling tty: Operation not permitted
May 23 04:16:40 x01 /sbin/mingetty[2965]: tty2: no controlling tty: Operation not permitted
May 23 04:16:45 x01 init: tty (/dev/tty2) main process (2965) terminated with status 1
May 23 04:16:45 x01 init: tty (/dev/tty2) main process ended, respawning
May 23 04:16:45 x01 init: tty (/dev/tty1) main process (2966) terminated with status 1
May 23 04:16:45 x01 init: tty (/dev/tty1) main process ended, respawning
May 23 04:16:45 x01 /sbin/mingetty[2968]: tty2: no controlling tty: Operation not permitted
May 23 04:16:45 x01 /sbin/mingetty[2969]: tty1: no controlling tty: Operation not permitted
May 23 04:16:50 x01 init: tty (/dev/tty2) main process (2968) terminated with status 1
May 23 04:16:50 x01 init: tty (/dev/tty2) main process ended, respawning
May 23 04:16:50 x01 init: tty (/dev/tty1) main process (2969) terminated with status 1
May 23 04:16:50 x01 init: tty (/dev/tty1) main process ended, respawning

Y así sucesivamente, hasta tal punto que me llena el log messages con un bucle.

Si voy a /etc/init tengo lo siguiente:

4 -rw-r--r-- 1 root root 97 May 23 03:05 console.conf
4 -rw-r--r-- 1 root root 412 Oct 10 2013 control-alt-delete.conf
4 -rw-r--r-- 1 root root 130 Mar 12 12:06 init-system-dbus.conf
4 -rw-r--r-- 1 root root 463 Oct 10 2013 kexec-disable.conf
4 -rw-r--r-- 1 root root 560 Oct 10 2013 plymouth-shutdown.conf
4 -rw-r--r-- 1 root root 357 Oct 10 2013 prefdm.conf
4 -rw-r--r-- 1 root root 505 Oct 10 2013 quit-plymouth.conf
4 -rw-r--r-- 1 root root 417 Oct 10 2013 rc.conf
4 -rw-r--r-- 1 root root 1046 Oct 10 2013 rcS.conf
4 -rw-r--r-- 1 root root 430 Oct 10 2013 rcS-emergency.conf
4 -rw-r--r-- 1 root root 725 Oct 10 2013 rcS-sulogin.conf
4 -rw-r--r-- 1 root root 1302 Oct 10 2013 serial.conf
4 -rw-r--r-- 1 root root 791 Oct 10 2013 splash-manager.conf
4 -rw-r--r-- 1 root root 473 Oct 10 2013 start-ttys.conf
4 -rw-r--r-- 1 root root 94 May 23 03:05 tty2.conf
4 -rw-r--r-- 1 root root 335 Oct 10 2013 tty.conf

La diferencia con los demás servers es que tengo console.conf y tty2.conf incluso una vez los borro si hago un reboot, me los vuelve a crear.

Estos ficheros contienen lo siguiente:

console.conf

start on stopped rc RUNLEVEL=[2345]
stop on runlevel [!2345]
respawn
exec /sbin/mingetty console

tty2.conf

start on stopped rc RUNLEVEL=[2345]
stop on runlevel [!2345]
respawn
exec /sbin/mingetty tty2

He ido a /etc/selinux y en config lo he puesto como permissive e incluso hasta disabled y me sigue sucediendo.

Si voy a /etc/sysconfig/init tengo la misma configuración que en los demás servidores.y que es la siguiente:

/etc/sysconfig/init

# color => new RH6.0 bootup
# verbose => old-style bootup
# anything else => new style bootup without ANSI colors or positioning
BOOTUP=color
# column to start "[ OK ]" label in
RES_COL=60
# terminal sequence to move to that column. You could change this
# to something like "tput hpa ${RES_COL}" if your terminal supports it
MOVE_TO_COL="echo -en \\033[${RES_COL}G"
# terminal sequence to set color to a 'success' color (currently: green)
SETCOLOR_SUCCESS="echo -en \\033[0;32m"
# terminal sequence to set color to a 'failure' color (currently: red)
SETCOLOR_FAILURE="echo -en \\033[0;31m"
# terminal sequence to set color to a 'warning' color (currently: yellow)
SETCOLOR_WARNING="echo -en \\033[0;33m"
# terminal sequence to reset to the default color.
SETCOLOR_NORMAL="echo -en \\033[0;39m"
# Set to anything other than 'no' to allow hotkey interactive startup...
PROMPT=yes
# Set to 'yes' to allow probing for devices with swap signatures
AUTOSWAP=no
# What ttys should gettys be started on?
ACTIVE_CONSOLES=/dev/tty[1-6]
# Set to '/sbin/sulogin' to prompt for password on single-user mode
# Set to '/sbin/sushell' otherwise
SINGLE=/sbin/sushell

En /etc/inittab

id:3:initdefault:

Escribo lo siguiente:

ps -ef | grep tty

root 889 1 0 03:06 tty1 00:00:00 /sbin/mingetty console
root 891 1 0 03:06 tty2 00:00:00 /sbin/mingetty tty2
root 913 1 0 03:06 tty3 00:00:00 /sbin/mingetty /dev/tty3
root 918 1 0 03:06 tty4 00:00:00 /sbin/mingetty /dev/tty4
root 924 1 0 03:06 tty5 00:00:00 /sbin/mingetty /dev/tty5
root 930 1 0 03:06 tty6 00:00:00 /sbin/mingetty /dev/tty6
root 3500 1 0 04:37 ? 00:00:00 /sbin/mingetty /dev/tty1
root 3501 1 0 04:37 ? 00:00:00 /sbin/mingetty /dev/tty2
root 3503 986 0 04:37 pts/0 00:00:00 grep tty

Y los procesos

/sbin/mingetty /dev/tty1
/sbin/mingetty /dev/tty2

El PID cambia, vamos que abre el proceso y lo vuelve a abrir con un PID diferente

Descarto cualquier tipo de intrusión, puesto que tengo políticas por IP, y los servicios web están con firewalls a nivel de aplicación, proxy reverso, etc. todo el sistema esta actualizado a la última con los repos oficiales de CentOS. Las aplicaciones web están actualizadas.

Domingo 25 de Mayo de 2014 decido retirar mi ticket, despues de estar 13 días sin soporte y decidí reinstalar de nuevo todo. solucionando el problema del servidor, ya no me hacia el bucle y todo funcionaba perfecto.

Hoy Miércoles 28 de Mayo de 2014

Me han reiniciado a la 01:43 de la madrugada cuatro servidores y en los cuatro, me aparece el mismo problema que antes con uno, ahora son los cuatro servidores.


¿Alguien sabe algo de esto? Tengo todo más que protegido y en cada uno de los servidores funciona con software servidor distintos.

Con 9 GB que dan en los VPS, y encima crean estos problemas, pues no lo veo lógico.

También tengo que decir que una vez se reinstala los servidores, hay un fichero llamado .p en el home root que es un binario y a saber que función hace y los tengo desde que se reinstalan.

Muchas gracias.

Recibir un cordial saludo.