Je suis juste curieux: quel peut être le but de redémarrer toutes les 30 minutes?
Rafał Cieślak
Réponses:
30
La meilleure façon de procéder dépendra de la raison pour laquelle vous souhaitez qu'Ubuntu redémarre toutes les demi-heures.
Je recommande donc de modifier votre question pour expliquer pourquoi vous souhaitez le faire.
Redémarrage toutes les 30 minutes et avertissement des utilisateurs avant chaque redémarrage:
En supposant que des personnes utilisent la machine, localement ou à distance, il est préférable d'éviter de redémarrer Ubuntu sous eux sans aucun avertissement. Par conséquent, plutôt que de planifier la rebootcommande, je recommande de planifier la shutdowncommande afin d'avertir l'utilisateur.
Pour planifier un arrêt toutes les demi-heures avec un avertissement 5 minutes avant, ajoutez ceci à /etc/crontab:
Vous n'avez pas vraiment besoin d'ajouter la première ligne, qui est un commentaire. Je l'ai inclus pour plus de clarté - quelque chose comme ça est déjà là.
Cela planifie le système pour redémarrer ( -r) cinq minutes après ( +5) l'exécution de la commande. Il s'exécute toutes les 30 minutes ( */30). Voir man cronet man 5 crontab.
Passez +5à autre chose pour changer le temps dont disposent les utilisateurs après avoir été avertis des redémarrages.
0,30sous minute fonctionnera également, si vous préférez cela. (De même, si c'était toutes les 20 minutes, vous pourriez écrire */20ou 0,20,40.)
Assurez-vous que se /sbintrouve dans la PATHvariable spécifiée près du haut de /etc/crontab. Sinon, shutdown(under command) devra être appelé comme /sbin/shutdown.
La commande s'exécutera toujours à la demi-heure si la machine est opérationnelle à ce moment-là . Cela entraînera l'annulation des arrêts toutes les demi-heures et leur exécution à 5 minutes et 35 minutes après l'heure.
Un avantage ici est qu'un administrateur peut annuler l'arrêt qui vient d'être annoncé avec sudo shutdown -c.
Si l'ordinateur est arrêté pendant les moments spécifiques où la commande planifiée doit être exécutée, il ne s'exécutera pas. Si cela ne correspond pas à vos besoins, vous devrez planifier vos redémarrages différemment. (Ceci n'est pas spécifique à l'utilisation de shutdownmais s'appliquerait également si vous planifiez reboot.) Dans ce cas, veuillez modifier votre question pour expliquer vos besoins spécifiques. (Je recommanderais anacroncela, mais vos intervalles de temps sont beaucoup trop courts.)
Permettre aux administrateurs d'empêcher plus facilement les redémarrages automatiques:
Vous voudrez peut-être configurer cela afin qu'il soit facile pour un administrateur de suspendre tous les redémarrages programmés automatiquement:
Cela planifie les redémarrages de la même manière - toutes les demi-heures, avec un avertissement de cinq minutes - sauf qu'il ne planifiera pas de redémarrage si un fichier appelé noautorebootexiste /etc.
Ce fichier de contrôle peut être créé par un administrateur avec:
sudo touch /etc/noautoreboot
Il peut être supprimé avec:
sudo rm /etc/noautoreboot
Notez que c'est si le fichier existe ou non , et non ce qu'il contient, qui compte.
Si le redémarrage est prévu et les utilisateurs sont avertis, alors que le fichier est créé, le (immédiatement à venir) redémarrage encore se produire.
Comment cela marche-t-il? Il utilise un court-circuit évalué ou opérateur ( ||) comme raccourci pour:
Cette réponse explique comment le court-circuit et / ou les opérateurs peuvent effectuer if- la thenlogique. Pour une explication brève, intuitive et très informelle, vous pouvez lire la commande de cette façon:
/etc/noautorebootexiste! Ou, cours shutdown -r +5.
Voir man [pour voir comment le test lui-même est effectué.
J'adore faire cela en disant au gestionnaire de session que nous voulons redémarrer. Cela peut être fait sans autorisations root, et nous obtenons une belle fenêtre qui nous avertit que le système va être redémarré - même nous pouvons annuler le redémarrage si nous le souhaitons.
La voie graphique - Méthode préférée
Installez gnome-scheduledepuis Ubuntu Software Center. Si vous ne voulez rien installer de plus, faites-le de la manière terminale.
Ouvrez à gnome-schedulepartir du tableau de bord, créez une nouvelle tâche répétée et définissez ces options:
Enregistrer et quitter. En supposant que vous utilisez nano(celui par défaut), appuyez sur Ctrl + o et Ctrl + x .
Veuillez noter que cela ne fonctionnera pas si votre AFFICHAGE est réellement différent de :0, et c'est la raison pour laquelle cette méthode n'est pas préférée. Mais, honnêtement, si vous redémarrez votre ordinateur toutes les 30 minutes, votre DISPLAY sera très probablement toujours :0.
Vous n'utilisez pas Gnome ou Unity?
Les deux méthodes expliquées ci-dessus dépendent de certains composants gnome, trouvés à la fois sur les sessions Gnome et sur Unity. Si vous voulez le faire sur un autre environnement (comme KDE de Kubuntu, LXDE de Kubuntu ...), vous feriez mieux de remplacer la commande par celle-ci à la place:
Cela ne demandera pas de confirmation et redémarrera immédiatement, mais fonctionnera dans tous les environnements, en supposant que vous n'avez pas désinstallé ConsoleKit manuellement, bien sûr.
Exécutez à sudo crontab -epartir de la ligne de commande et ajoutez cette ligne au fichier:
0,30 * * * * reboot
Cela indique au système d'exécuter la commande reboottoutes les 30 minutes en tant que root. Pour un aperçu de la syntaxe temporelle, voir ici: http://linuxmoz.com/crontab-syntax-tutorial/
Cela ne fonctionnera pas, car il rebootdoit être exécuté en tant que root, et cela l'ajoute à la crontab personnelle de l'utilisateur, il s'exécute donc en tant qu'utilisateur non root. (La même chose avec sudo rebootne fonctionnera pas non plus, car sudoessaiera de demander un mot de passe et échouera.) /etc/crontabDevrait être utilisé à la place (veuillez noter que sa syntaxe est légèrement différente).
Eliah Kagan
1
Vous pouvez émettre sudo crontab -epuis créer une entrée cron.
Tass
-3
Permet cronde planifier un travail toutes les 30 minutes. Pointez ce travail sur un script shell qui a simplement
reboot
en elle.
Étant donné que crons'exécute en tant que root, vous ne devriez pas avoir à faire quoi que ce soit de spécial en termes d'autorisations.
Mise à jour
Oui, en fait, sur aucun de mes systèmes, je n'autorise les crontabs basées sur l'utilisateur (il existe de meilleures façons de permettre aux utilisateurs d'effectuer des tâches planifiées au niveau de l'utilisateur) cron a été conçu dès le début uniquement pour l'automatisation du système et non pour les utilisateurs de planifier des tâches ordinaires Tâches. Des choses telles que les rotations de journaux (qui se produisent encore aujourd'hui)
Le redémarrage DOIT être exécuté en tant que root pour fonctionner correctement, l'alternative est de définir son sticky bit, de sorte que lorsqu'il est exécuté en tant qu'utilisateur normal, il s'exécute en tant que root et fonctionne comme prévu, mais en faisant cela, vous ouvrez ensuite votre serveur pour permettre à regular les utilisateurs de le redémarrer à volonté.
Vous pouvez même éventuellement automatiser un appel à SUDO, mais je dois creuser dans celui-ci, je ne sais pas si vous pouvez automatiser le besoin d'un mot de passe avec SUDO (je ne l'utilise pas souvent, je préfère simplement passer directement à une racine shell utilisant SU)
Si vous le configurez dans crontab à l'échelle du système, tout est exécuté en tant que root, donc ma déclaration est exacte (j'ai juste négligé de mentionner que celle à l'échelle du système devrait être utilisée)
Quant à votre question "Pourquoi l'envelopper dans un script?" Eh bien pourquoi pas? Si l'OP le met dans un script shell, à un moment donné dans le futur, il doit y ajouter, il ajoute simplement au script, au lieu d'avoir à ouvrir crontab localiser le travail, le supprimer, le remplacer par un script shell, puis écrivez un script avec l'ancien + nouveau.
Plus de 20 ans en tant qu'administrateur / développeur Sys travaillant avec des systèmes aussi loin que Ultrix / Solaris et même VAX m'a appris un point majeur.
Si vous pouvez le rendre plus facile au début, cela reste facile pendant toute sa durée de vie.
Je n'ai vraiment pas cette attitude "minimaliste" que beaucoup d'administrateurs de systèmes modernes ont, où faire le moins possible est la clé du succès. La plupart des serveurs de nos jours sont facilement 20 fois + plus puissants que tout ce que j'ai jamais commencé, et ce type de scénario (Wrapping dans des scripts shell) était alors recommandé, donc il n'y a vraiment aucun argument pour ne pas le faire maintenant.
À moins que vous ne vouliez vraiment aller hardcore Unix / Linux, auquel cas étiqueter le tout sur l'entrée cron, et tout diriger ensemble comme il se doit :-)
Cependant, je m'égare, et je comprends aussi que beaucoup de gars ces jours-ci sont jetés au fond et disent de faire fonctionner les choses, en tant que tels, ils n'ont pas le temps (et généralement l'envie) de s'asseoir et d'apprendre de nouvelles techniques (ou vieux dans ce cas) ou même envie de jouer avec ce truc en dehors du travail.
Personnellement, j'ai un seul serveur parmi ceux que je lance qui est dédié uniquement à moi, donc je peux tester des choses comme ça ... qui est mieux A ou B, donc ce n'est pas sans raison que je conseille sur l'un des cette.
Réponses:
La meilleure façon de procéder dépendra de la raison pour laquelle vous souhaitez qu'Ubuntu redémarre toutes les demi-heures.
Je recommande donc de modifier votre question pour expliquer pourquoi vous souhaitez le faire.
Redémarrage toutes les 30 minutes et avertissement des utilisateurs avant chaque redémarrage:
En supposant que des personnes utilisent la machine, localement ou à distance, il est préférable d'éviter de redémarrer Ubuntu sous eux sans aucun avertissement. Par conséquent, plutôt que de planifier la
rebootcommande, je recommande de planifier lashutdowncommande afin d'avertir l'utilisateur.Pour planifier un arrêt toutes les demi-heures avec un avertissement 5 minutes avant, ajoutez ceci à
/etc/crontab:Vous n'avez pas vraiment besoin d'ajouter la première ligne, qui est un commentaire. Je l'ai inclus pour plus de clarté - quelque chose comme ça est déjà là.
-r) cinq minutes après (+5) l'exécution de la commande. Il s'exécute toutes les 30 minutes (*/30). Voirman cronetman 5 crontab.+5à autre chose pour changer le temps dont disposent les utilisateurs après avoir été avertis des redémarrages.0,30sous minute fonctionnera également, si vous préférez cela. (De même, si c'était toutes les 20 minutes, vous pourriez écrire*/20ou0,20,40.)/sbintrouve dans laPATHvariable spécifiée près du haut de/etc/crontab. Sinon,shutdown(undercommand) devra être appelé comme/sbin/shutdown.La commande s'exécutera toujours à la demi-heure si la machine est opérationnelle à ce moment-là . Cela entraînera l'annulation des arrêts toutes les demi-heures et leur exécution à 5 minutes et 35 minutes après l'heure.
sudo shutdown -c.shutdownmais s'appliquerait également si vous planifiezreboot.) Dans ce cas, veuillez modifier votre question pour expliquer vos besoins spécifiques. (Je recommanderaisanacroncela, mais vos intervalles de temps sont beaucoup trop courts.)Permettre aux administrateurs d'empêcher plus facilement les redémarrages automatiques:
Vous voudrez peut-être configurer cela afin qu'il soit facile pour un administrateur de suspendre tous les redémarrages programmés automatiquement:
Cela planifie les redémarrages de la même manière - toutes les demi-heures, avec un avertissement de cinq minutes - sauf qu'il ne planifiera pas de redémarrage si un fichier appelé
noautorebootexiste/etc.Ce fichier de contrôle peut être créé par un administrateur avec:
Il peut être supprimé avec:
Notez que c'est si le fichier existe ou non , et non ce qu'il contient, qui compte.
Si le redémarrage est prévu et les utilisateurs sont avertis, alors que le fichier est créé, le (immédiatement à venir) redémarrage encore se produire.
Comment cela marche-t-il? Il utilise un court-circuit évalué ou opérateur (
||) comme raccourci pour:Cette réponse explique comment le court-circuit et / ou les opérateurs peuvent effectuer
if- lathenlogique. Pour une explication brève, intuitive et très informelle, vous pouvez lire la commande de cette façon:Voir
man [pour voir comment le test lui-même est effectué.la source
J'adore faire cela en disant au gestionnaire de session que nous voulons redémarrer. Cela peut être fait sans autorisations root, et nous obtenons une belle fenêtre qui nous avertit que le système va être redémarré - même nous pouvons annuler le redémarrage si nous le souhaitons.
La voie graphique - Méthode préférée
Installez
gnome-scheduledepuis Ubuntu Software Center. Si vous ne voulez rien installer de plus, faites-le de la manière terminale.Ouvrez à
gnome-schedulepartir du tableau de bord, créez une nouvelle tâche répétée et définissez ces options:dbus-send --print-reply --dest="org.gnome.SessionManager" /org/gnome/SessionManager org.gnome.SessionManager.RebootLaissez les autres options à leurs valeurs par défaut. Cliquez sur Add .
The Terminal Way - Pas besoin de logiciel supplémentaire
Exécutez à partir du terminal:
Ajoutez cette ligne:
Enregistrer et quitter. En supposant que vous utilisez
nano(celui par défaut), appuyez sur Ctrl + o et Ctrl + x .Veuillez noter que cela ne fonctionnera pas si votre AFFICHAGE est réellement différent de
:0, et c'est la raison pour laquelle cette méthode n'est pas préférée. Mais, honnêtement, si vous redémarrez votre ordinateur toutes les 30 minutes, votre DISPLAY sera très probablement toujours:0.Vous n'utilisez pas Gnome ou Unity?
Les deux méthodes expliquées ci-dessus dépendent de certains composants gnome, trouvés à la fois sur les sessions Gnome et sur Unity. Si vous voulez le faire sur un autre environnement (comme KDE de Kubuntu, LXDE de Kubuntu ...), vous feriez mieux de remplacer la commande par celle-ci à la place:
Cela ne demandera pas de confirmation et redémarrera immédiatement, mais fonctionnera dans tous les environnements, en supposant que vous n'avez pas désinstallé ConsoleKit manuellement, bien sûr.
la source
Exécutez à
sudo crontab -epartir de la ligne de commande et ajoutez cette ligne au fichier:0,30 * * * * rebootCela indique au système d'exécuter la commande
reboottoutes les 30 minutes en tant que root. Pour un aperçu de la syntaxe temporelle, voir ici: http://linuxmoz.com/crontab-syntax-tutorial/la source
rebootdoit être exécuté en tant queroot, et cela l'ajoute à la crontab personnelle de l'utilisateur, il s'exécute donc en tant qu'utilisateur non root. (La même chose avecsudo rebootne fonctionnera pas non plus, carsudoessaiera de demander un mot de passe et échouera.)/etc/crontabDevrait être utilisé à la place (veuillez noter que sa syntaxe est légèrement différente).sudo crontab -epuis créer une entrée cron.Permet
cronde planifier un travail toutes les 30 minutes. Pointez ce travail sur un script shell qui a simplementen elle.
Étant donné que
crons'exécute en tant que root, vous ne devriez pas avoir à faire quoi que ce soit de spécial en termes d'autorisations.Mise à jour
Oui, en fait, sur aucun de mes systèmes, je n'autorise les crontabs basées sur l'utilisateur (il existe de meilleures façons de permettre aux utilisateurs d'effectuer des tâches planifiées au niveau de l'utilisateur) cron a été conçu dès le début uniquement pour l'automatisation du système et non pour les utilisateurs de planifier des tâches ordinaires Tâches. Des choses telles que les rotations de journaux (qui se produisent encore aujourd'hui)
Le redémarrage DOIT être exécuté en tant que root pour fonctionner correctement, l'alternative est de définir son sticky bit, de sorte que lorsqu'il est exécuté en tant qu'utilisateur normal, il s'exécute en tant que root et fonctionne comme prévu, mais en faisant cela, vous ouvrez ensuite votre serveur pour permettre à regular les utilisateurs de le redémarrer à volonté.
Vous pouvez même éventuellement automatiser un appel à SUDO, mais je dois creuser dans celui-ci, je ne sais pas si vous pouvez automatiser le besoin d'un mot de passe avec SUDO (je ne l'utilise pas souvent, je préfère simplement passer directement à une racine shell utilisant SU)
Si vous le configurez dans crontab à l'échelle du système, tout est exécuté en tant que root, donc ma déclaration est exacte (j'ai juste négligé de mentionner que celle à l'échelle du système devrait être utilisée)
Quant à votre question "Pourquoi l'envelopper dans un script?" Eh bien pourquoi pas? Si l'OP le met dans un script shell, à un moment donné dans le futur, il doit y ajouter, il ajoute simplement au script, au lieu d'avoir à ouvrir crontab localiser le travail, le supprimer, le remplacer par un script shell, puis écrivez un script avec l'ancien + nouveau.
Plus de 20 ans en tant qu'administrateur / développeur Sys travaillant avec des systèmes aussi loin que Ultrix / Solaris et même VAX m'a appris un point majeur.
Si vous pouvez le rendre plus facile au début, cela reste facile pendant toute sa durée de vie.
Je n'ai vraiment pas cette attitude "minimaliste" que beaucoup d'administrateurs de systèmes modernes ont, où faire le moins possible est la clé du succès. La plupart des serveurs de nos jours sont facilement 20 fois + plus puissants que tout ce que j'ai jamais commencé, et ce type de scénario (Wrapping dans des scripts shell) était alors recommandé, donc il n'y a vraiment aucun argument pour ne pas le faire maintenant.
À moins que vous ne vouliez vraiment aller hardcore Unix / Linux, auquel cas étiqueter le tout sur l'entrée cron, et tout diriger ensemble comme il se doit :-)
Cependant, je m'égare, et je comprends aussi que beaucoup de gars ces jours-ci sont jetés au fond et disent de faire fonctionner les choses, en tant que tels, ils n'ont pas le temps (et généralement l'envie) de s'asseoir et d'apprendre de nouvelles techniques (ou vieux dans ce cas) ou même envie de jouer avec ce truc en dehors du travail.
Personnellement, j'ai un seul serveur parmi ceux que je lance qui est dédié uniquement à moi, donc je peux tester des choses comme ça ... qui est mieux A ou B, donc ce n'est pas sans raison que je conseille sur l'un des cette.
la source