El comando reboot -f
nunca regresa (a menos que no tenga permiso para provocar un reinicio). En el punto donde se emite, el cliente SSH está esperando algo que hacer, que podría ser:
- el servidor SSH notifica al cliente que sucedió algo que requiere su atención, por ejemplo, que hay algo que mostrar o que el comando remoto ha finalizado;
- algún evento en el lado del cliente, como una señal para retransmitir;
- un temporizador que se activa para que el cliente envíe un mensaje de alerta (y cierre la conexión si el servidor no responde).
Dado que el proceso del servidor SSH está inactivo, el cliente SSH no morirá hasta que se active el temporizador.
Si corres ssh remotehost 'reboot -f >/dev/null &'
, entonces lo que sucede es:
- El shell remoto inicia el
reboot
comando en segundo plano.
- Debido a que el comando de shell del lado del servidor ha salido y no hay ningún proceso que mantenga abierto el descriptor de archivo para la salida estándar, el servidor SSH cierra la conexión.
- El
reboot
comando hace que la máquina se reinicie.
Sin embargo, esto no es confiable: dependiendo del tiempo, el paso 3 podría ocurrir antes del paso 2. Agregar un temporizador hace que esto sea poco probable:
ssh remotehost '{ sleep 1; reboot -f; } >/dev/null &'
Para estar absolutamente seguro de que el lado del servidor está comprometido a ejecutarse reboot
, mientras se asegura de que en realidad no se reinicie antes de notificar al cliente que está comprometido, necesita una notificación adicional para ir del servidor al cliente. Esto se puede generar a través de la conexión SSH, pero se complica.