Respuestas:
at 18:00 shutdown nowcrea un trabajo "at", que se realiza en el momento especificado por el atdemonio o tal vez el crondemonio, dependiendo de su sistema.
shutdown 18:00inicia un proceso en su shell que espera hasta el tiempo especificado y luego realiza el apagado. Este comando se puede terminar si, por ejemplo, se termina su sesión de shell.
El resultado neto en la mayoría de los casos será el mismo: el sistema se apaga a las 18:00.
Una diferencia es que si usa at, el trabajo se almacenará y si el sistema se apaga por algún otro medio antes de las 18:00, al reiniciar nuevamente, el trabajo aún estará esperando para ejecutarse; Si ya pasó el tiempo, el apagado se realizará de inmediato, lo que podría ser bastante inesperado.
Otra diferencia es que shutdown 18:00creará un /run/nologinarchivo 5 minutos antes de la hora programada para evitar que las personas inicien sesión después de ese momento. También se enviarán mensajes de difusión para advertir a los usuarios registrados que el sistema está a punto de cerrarse.
Debe tener en cuenta estas diferencias para decidir cuál usar.
nohupo disownlo que sea, si cerrar la sesión normalmente mata a ejecutar procesos en segundo plano. Los diferentes sistemas pueden tener diferentes valores predeterminados para eso. (Supongo que realmente sudo shutdowntodavía hay un proceso en ejecución, más bien solo indica initque se inicie un temporizador de apagado. Esto último podría ser lo que sucede, pero no lo he comprobado recientemente. Oh, pero @JdeBP sí; vea esa respuesta )
atpara que funcione a través de en cronlugar de atd?
Si tiene CentOS 7, tiene un sistema operativo systemd y la respuesta es diferente.
at 18:00 shutdown nowtodavía se programa a través del atsubsistema, pero ese shutdowncomando, así como el que invocas directamente shutdown 18:00, es diferente. En realidad es el systemctlprograma de systemd . systemctlhace las cosas de manera diferente.
En primer lugar, systemctlenvía la solicitud de apagado programada para que sea procesada por un demonio, como en el atcaso. Sin embargo, este es un demonio systemd, específicamente logind(el systemd-shutdownddemonio se eliminó de systemd en mayo de 2015, cuyo cambio se ha filtrado desde entonces a versiones menores posteriores de CentOS 7), no el atsubsistema. systemctlhabla un protocolo interno a un intermediario de Desktop Bus (en todo el sistema) con el que a su vez se comunica logind.
Entonces, como en el atcaso, no hay ningún shutdownproceso allí sentado, contando y generando los wallmensajes. Por lo tanto, uno puede cerrar sesión y esto no afectará el cronograma, y cancelar no es tan simple como simplemente interrumpir / matar el proceso en primer plano de la sesión de inicio de sesión. Al igual que con at.
Todavía hay mensajes, a diferencia del atcaso, pero son emitidos por logind. Además, a diferencia del atcaso, el trabajo programado no persiste en los reinicios del sistema, por lo que un apagado real cancela uno programado. No es un archivo en el sistema de archivos, pero está bajo /run/systemd/shutdownel que almacenar de forma no persistente.
Las diferencias adicionales son que solo puede haber un apagado programado a la vez, mientras que uno puede enviar múltiples attrabajos, y Policy Kit aplicará reglas para shutdownejecutarse en un contexto de sesión sin inicio de sesión como un attrabajo diferente a las reglas aplicadas para shutdownejecutarse en contexto de sesión de inicio de sesión. Este último podría ser más permisivo, permitiendo (por ejemplo) que un usuario no privilegiado que haya iniciado sesión en la sesión de inicio de sesión activa cierre el sistema.
shutdown 18:00comienza un proceso en su shell que espera". ¿Qué pasa si cierras sesión antes?