Me gustaría programar un reinicio de mi Ubuntu cada 30 minutos. ¿Hay algún comando o una forma gráfica de hacerlo?

La mejor manera de hacerlo dependerá de por qué desea que Ubuntu se reinicie cada media hora.

^{Por lo tanto, recomiendo editar su pregunta para explicar por qué desea hacer esto.}

Reiniciar cada 30 minutos y advertir a los usuarios antes de cada reinicio:

Suponiendo que las personas puedan estar usando la máquina, ya sea local o remotamente, es mejor evitar reiniciar Ubuntu sin ninguna advertencia. Por lo tanto, en lugar de programar el rebootcomando, recomiendo programar el shutdowncomando para que advierta al usuario.

Para programar un apagado cada media hora con una advertencia 5 minutos antes, agregue esto a /etc/crontab:

#minute hour    mday    month   wday    user    command
*/30    *       *       *       *       root    shutdown -r +5

^{En realidad, no tiene que agregar la primera línea, que es un comentario. Lo he incluido para mayor claridad, algo así ya está allí.}

• Esto programará el sistema para que se reinicie ( -r) cinco minutos después de que ( +5) se ejecute el comando. Se ejecuta cada marca de cada media hora ( */30). Ver man crony man 5 crontab.
• Cambie +5a otra cosa para cambiar el tiempo que los usuarios tienen después de ser advertidos de reinicios.
• 0,30en menos de un minuto también funcionará, si lo prefiere. (Del mismo modo, si fuera cada 20 minutos, podría escribir */20o 0,20,40).
• Asegúrese de que /sbinesté en la PATHvariable especificada cerca de la parte superior de /etc/crontab. De lo contrario, shutdown(debajo command) tendrá que ser invocado como /sbin/shutdown.

El comando siempre se ejecutará en la marca de media hora, si la máquina está funcionando en ese momento . Esto hará que las paradas se anuncien cada media hora y se realicen a los 5 minutos y 35 minutos después de la hora.

• Un beneficio aquí es que un administrador puede cancelar el cierre recién anunciado con sudo shutdown -c.
• Si la computadora está inactiva durante los momentos específicos en que se ejecutará el comando programado, no se ejecutará. Si eso no es adecuado para sus necesidades, tendrá que programar sus reinicios de manera diferente. (Esto no es específico para el uso de, shutdownpero se aplicaría igualmente si estuviera programando reboot). En ese caso, edite su pregunta para explicar sus necesidades específicas. (Lo recomendaría anacronpara esto, pero sus intervalos de tiempo son demasiado cortos).

Facilitando a los administradores evitar que se reinicien automáticamente:

Es posible que desee configurar esto para que sea fácil para un administrador suspender todos los reinicios programados automáticamente:

#minute hour    mday    month   wday    user    command
*/30    *       *       *       *       root    [ -e /etc/noautoreboot ] || shutdown -r +5

Esta programación se reinicia de la misma manera, cada media hora, con cinco minutos de advertencia, excepto que no programará un reinicio si noautorebootexiste un archivo llamado /etc.

• Este archivo de control puede ser creado por un administrador con:

  sudo touch /etc/noautoreboot
  

• Se puede eliminar con:

  sudo rm /etc/noautoreboot
  

• Tenga en cuenta que lo que importa es si el archivo existe o no , no lo que contiene.

• Si el reinicio está programado y se advierte a los usuarios, entonces se crea el archivo, el reinicio (próximo) seguirá ocurriendo.

• ¿Como funciona esto? Utiliza un short-circuit -evaluated u operator ( ||) como abreviatura para:

  Si /etc/noautoreboot no existe, corre shutdown -r +5.

  Esta respuesta explica cómo pueden funcionar los operadores de cortocircuito y / o lógica if: thenlógica. Para una explicación breve, intuitiva y altamente informal, puede leer el comando de esta manera:

  /etc/noautorebootexiste! O corre shutdown -r +5.

  Vea man [para ver cómo se realiza la prueba en sí.

Me encanta hacer esto diciéndole al Administrador de sesión que queremos reiniciar. Esto se puede hacer sin permisos de root, y obtenemos una buena ventana que nos advierte que el sistema se reiniciará, incluso podemos cancelar el reinicio si lo deseamos.

La forma gráfica: método preferido

Instalar gnome-scheduledesde el Centro de software de Ubuntu. Si no desea instalar nada adicional, hágalo de la manera Terminal.

Abra gnome-scheduledesde el tablero, cree una nueva tarea repetida y configure estas opciones:

• Descripción: lo que quieras
• Mando: dbus-send --print-reply --dest="org.gnome.SessionManager" /org/gnome/SessionManager org.gnome.SessionManager.Reboot
• Elija la aplicación X justo debajo del comando.
• Hora y fecha, avanzado:
  • Minuto: 0,30

Deje las otras opciones en sus valores predeterminados. Haga clic en Agregar .

The Terminal Way: sin necesidad de software adicional

Ejecutar desde la terminal:

crontab -e

Agrega esta línea:

0,30 * * * * DISPLAY=:0 dbus-send --print-reply --dest="org.gnome.SessionManager" /org/gnome/SessionManager org.gnome.SessionManager.Reboot

Guardar la salida. Suponiendo que esté utilizando nano(el predeterminado), presione Ctrl + o y Ctrl + x .

Tenga en cuenta que esto no funcionará si su PANTALLA es realmente diferente :0, y esa es la razón por la cual este método no es preferido. Pero, sinceramente, si reinicia su computadora cada 30 minutos, su PANTALLA probablemente siempre lo será :0.

¿No estás usando Gnome o Unity?

Ambos métodos explicados anteriormente dependen de algunos componentes de gnome, que se encuentran tanto en las sesiones de Gnome como en Unity. Si desea hacer esto en otros entornos (como KDE de Kubuntu, LXDE de Kubuntu ...), mejor reemplace el comando con este:

dbus-send --system --print-reply --dest="org.freedesktop.ConsoleKit" /org/freedesktop/ConsoleKit/Manager org.freedesktop.ConsoleKit.Manager.Restart

Esto no solicitará confirmación y se reiniciará de inmediato, pero funcionará en todos los entornos, suponiendo que no haya desinstalado manualmente ConsoleKit, por supuesto.

Ejecute sudo crontab -edesde la línea de comando y agregue esta línea al archivo:

0,30 * * * * reboot

Esto le dice al sistema que ejecute el comando rebootcada 30 minutos como root. Para obtener una descripción general de la sintaxis de tiempo, consulte aquí: http://linuxmoz.com/crontab-syntax-tutorial/

Úselo cronpara programar un trabajo cada 30 minutos. Apunte ese trabajo a un script de shell que simplemente tiene

reboot

en eso.

Dado que se cronejecuta como root, no debería necesitar hacer nada especial en términos de permisos.

Actualizar

Sí, de hecho, nunca en ninguno de mis sistemas permití crontabs basados ​​en el usuario (Hay mejores formas de permitir que los usuarios realicen tareas programadas a nivel de usuario) cron fue diseñado desde el principio exclusivamente para la automatización del sistema y no para que los usuarios programen Tareas. Cosas como las rotaciones de registros (que todavía ocurre hoy)

El reinicio DEBE ejecutarse como root para que funcione correctamente, la alternativa es establecer un bit fijo, de modo que cuando se ejecuta como un usuario normal realmente se ejecute como root y funcione como se espera, pero al hacerlo, abre el servidor para permitir usuarios para reiniciarlo a voluntad.

Incluso podría automatizar una llamada a SUDO, pero necesito profundizar en esa, no estoy seguro de si puede automatizar la necesidad de una contraseña con SUDO (no la uso a menudo, prefiero simplemente ir directamente a una raíz shell utilizando SU)

Si lo configura en el crontab de todo el sistema, entonces todo se ejecuta como root, por lo que mi declaración es precisa (solo omití mencionar que se debe usar el de todo el sistema)

En cuanto a su pregunta "¿Por qué envolverlo en un guión?" ¿Bueno, por qué no? Si el OP lo coloca en un script de shell, en algún momento en el futuro necesita agregarle, simplemente agrega al script, en lugar de tener que abrir crontab para localizar el trabajo, eliminarlo, reemplazarlo con un script de shell, luego escribe un script con el viejo + nuevo en.

Más de 20 años como Sys Admin / Developer trabajando con sistemas desde Ultrix / Solaris e incluso VAX me ha enseñado un punto importante.

Si puede facilitarlo al principio, entonces sigue siendo fácil para toda la vida.

Realmente no entiendo esta actitud "minimalista" que tienen muchos administradores de sistemas modernos, donde hacer lo menos posible es la clave del éxito. La mayoría de los servidores en estos días son fácilmente más de 20 veces más potentes que cualquier cosa en la que haya comenzado, y este tipo de escenario (envoltura en scripts de shell) era una práctica recomendada entonces, por lo que realmente no hay argumento para no hacerlo ahora.

A menos que realmente quiera ir a Unix / Linux hardcore, en cuyo caso etiquetarlo todo en la entrada cron y juntar todo de la manera en que debería hacerse :-)

Sin embargo, estoy divagando, y también entiendo que muchos hombres en estos días son arrojados al fondo y se les dice que hagan que las cosas funcionen, por lo que les falta el tiempo (y generalmente la inclinación) para sentarse y aprender sobre nuevas técnicas (o viejo en este caso) o incluso querer jugar con estas cosas fuera del trabajo.

Personalmente, tengo un solo servidor entre los que ejecuto que está dedicado exclusivamente para que juegue, para que pueda probar cosas como esta ... que es mejor A o B, por lo que no sin razón aconsejo sobre cualquiera de esta.