¿Cómo sabe mi administrador de sistemas que no he reiniciado mi sistema?

Recibí un correo electrónico del administrador de mi sistema que decía que necesitaba reiniciar mi sistema para aplicar algunos parches. Me había olvidado de eso y después de un par de horas recibí otro correo informándome que aún no había reiniciado mi sistema.

Desde entonces he reiniciado mi sistema, pero me sorprende cómo sabrían si hubiera reiniciado mi máquina o no. ¿Alguien puede explicar cómo funciona esto?

Se puede hacer una forma rápida de verificar esto de forma remota utilizando SNMP (siempre que su SysAdmin lo haya configurado en su red):

admin@yourcompany:~$ snmpwalk -v 2c -c <snmpstring> MachineName sysUpTimeInstance
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks: (9461615) 1 day, 2:16:56.15

Lo más probable es que los datos sean sondeados y almacenados en un sistema de gestión / monitoreo de red de algún tipo (es decir, Nagios o Cacti).

En caso de que alguien esté interesado en jugar con el snmpwalkcomando, vea la respuesta aquí para obtener una configuración básica de SNMP configurada en su sistema.

Un método simple será verificar la salida del uptimecomando, que muestra cuánto tiempo ha estado ejecutando el sistema sin apagar / reiniciar.

Salida de muestra:

saji@geeklap:~$ uptime
12:41:29 up  3:08,  2 users,  load average: 1.06, 0.85, 0.86

Dice que mi sistema ha estado encendido durante 3 horas y 8 minutos.

El administrador puede configurar un script de shell para utilizar uptimeo utilizar algún otro método, como se detalla en este enlace . Otro método que el administrador puede utilizar es configurar un correo electrónico para enviarlo al apagar o reiniciar el sistema, los detalles están disponibles en este enlace .

@ saji89 mencionó el uptimecomando. Iré un paso más abajo, y simplemente postularé que el administrador del sistema tiene un script en algún lugar que se conecta a cada computadora y hace un cat /proc/uptime(o algo equivalente). El primer campo de la salida es el tiempo, en segundos, desde el último reinicio del sistema, que es mucho más fácil de analizar que la salida de uptime. Por ejemplo, el ordenador da un primer campo de tiempo de actividad 1441218.24con uptimeregresar up 16 days, 16:20. 1441218 segundos son 16 días más 58818 segundos, y 58818 segundos son 16 1/3 horas. 16 días 16 1/3 horas.

Cuando conoce el período máximo de tiempo desde que el sistema debería haberse reiniciado, estos datos hacen que sea trivial verificar si el sistema se ha reiniciado desde entonces o no.

Podría hacerse a través de una herramienta de monitoreo como Nagios, o mediante un script separado que el administrador del sistema mantiene en su computadora (o más bien accesible a través de ella, me imagino) que se conecta a cada computadora por turnos o en paralelo e imprime la hora desde el último reinicio en algún formato. Todo depende de cuán elaborado sea hacerlo.

Otra forma, solo por completar, es mirar a /var/log/wtmptravés del último comando. Ejemplo:

$ last reboot
reboot   system boot  3.2.0-36-generic Thu Jan 24 16:25 - 17:42 (1+01:17)   

wtmp begins Tue Jan  1 06:30:03 2013

Este método es el favorito porque también resulta ser el mnemónico perfecto.

Q: When did the last reboot occur? 
A: Just type 'last reboot'

Cuando se actualiza un paquete que requiere un reinicio apt, reboot-requiredse crea un archivo llamado /var/run/. El administrador del sistema puede verificar la presencia de este archivo de forma remota para determinar si es necesario reiniciar debido a las actualizaciones.

Esta ...

aplicar algunos parches

Es la parte clave.

Si el administrador es bueno, probablemente configuró las actualizaciones desde SU máquina para que las PC no tengan que descargar el mismo archivo de la web. Si es así, puede ver desde su propia máquina quién descargó los parches.

Luego, solo tiene que mirar las direcciones IP de los sistemas que cargaron los parches y enviar y enviar correos electrónicos a aquellos que no lo hicieron. Ese correo electrónico puede incluso ser un correo generado automáticamente. Imagina que hay 500 máquinas. Verificar manualmente cada uno de ellos es una pérdida de tiempo si hay varios métodos en los que puede hacerlo desde su propia máquina.

Una razón muy importante para hacerlo de esta manera: un administrador necesita tener control sobre lo que está sucediendo en los sistemas que necesita mantener. Por lo tanto, siempre debe tener un único punto de control (es decir, su propia máquina donde tenga todas las herramientas) donde pueda ver el estado de cualquier máquina.

Hay varios métodos válidos descritos en las respuestas. Iniciar sesión y verificar el tiempo de actividad sería extraño para una gran empresa, pero factible para una más pequeña. El administrador del sistema podría haber estado comprobando a través de SNMP, pero el mismo argumento de "problema" podría usarse allí.

Las situaciones más probables son, en lo que a mí respecta:

1. El administrador del sistema ejecuta algún tipo de software de verificación, probablemente Nagios, que verifica si hay problemas en grupos de computadoras. Algo como el complemento NRPE se usará para la mayoría de los sistemas y puede mostrarle tiempo de actividad (aparte del disco, usuarios registrados, etc.).
2. Se puede usar un método similar para verificar qué se está ejecutando y dónde. Si se pueden verificar los parches que se actualizarán (qué kernel está utilizando), el script "¿están todos los usuarios actualizados?" Todavía apuntará a su computadora por estar en un estado "malo".

Si el sistema está conectado a una red que él controla, el administrador del sistema puede simplemente mirar el conmutador o el servidor dhcp para ver cuánto tiempo ha estado activa su conexión de red. Eso también le dirá que no ha reiniciado.