Як автоматично перезапускати кожні 30 хвилин?


14

Я хотів би запланувати перезавантаження мого Ubuntu кожні 30 хвилин. Чи є якась команда чи графічний спосіб це зробити?


12
Мені просто цікаво: яка може бути мета перезавантаження кожні 30 хвилин?
Rafał Cieślak

Відповіді:


30

Найкращий спосіб зробити це залежатиме від того, чому ви хочете, щоб Ubuntu перезапускався кожні півгодини.

Тож рекомендую відредагувати своє запитання, щоб пояснити, чому ви хочете це зробити.

Перезавантаження кожні 30 хвилин та попередження користувачів перед кожним перезавантаженням:

Якщо припустити, що люди можуть користуватися машиною, локально чи віддалено, краще уникати перезавантаження Ubuntu з-під них без будь-якого попередження. Тому, замість того, щоб планувати rebootкоманду, я рекомендую планувати shutdownкоманду, щоб вона попереджала користувача.

Щоб запланувати відключення кожні півгодини з попередженням 5 хвилин до цього, додайте це до /etc/crontab:

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

Насправді вам не потрібно додавати лінію кулака, що є коментарем. Я включив це для наочності - щось подібне вже є.

  • Це дозволить запланувати роботу системи для перезавантаження ( -r) п'ять хвилин після ( +5) команди. Він працює кожні кожні півгодини позначки ( */30). Дивіться man cronі man 5 crontab.
  • Перейдіть +5на щось інше, щоб змінити кількість користувачів після попередження про перезавантаження.
  • 0,30за хвилину також буде працювати, якщо ви віддаєте перевагу. (Так само, якби кожні 20 хвилин, ви могли б написати */20або 0,20,40.)
  • Переконайтеся, що /sbinв PATHзмінній вказано вгорі /etc/crontab. В іншому випадку shutdown(під command) доведеться викликати як /sbin/shutdown.

Команда завжди буде виконуватись за півгодинної позначки, якщо машина в цей час працює і працює . Це призведе до того, що зупинки оголошуватимуться кожні півгодини та проводяться за 5 хвилин та 35 хвилин минулої години.

  • Одна з переваг тут полягає в тому, що адміністратор може скасувати щойно оголошене припинення роботи sudo shutdown -c.
  • Якщо комп'ютер не працює протягом певного часу, коли слід виконати заплановану команду, він не запуститься. Якщо це не відповідає вашим потребам, вам доведеться по-різному запланувати перезавантаження. (Це не специфічно для використання, shutdownале застосовуватиметься однаково, якщо ви плануєте reboot.) У такому випадку, будь ласка, відредагуйте своє запитання, щоб пояснити ваші конкретні потреби. (Я рекомендую anacronдля цього, але ваші часові проміжки занадто короткі.)

Полегшаючи адміністраторам запобігати взагалі автоматичним перезавантаженням:

Ви можете налаштувати це так, щоб адміністратору було легко призупинити всі автоматично заплановані перезавантаження:

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

Цей графік перезавантажується так само - кожні півгодини, з попередженням п'яти хвилин - за винятком того, що він не планує перезавантажити, якщо файл, який називається, noautorebootіснує в /etc.

  • Цей файл управління може бути створений адміністратором за допомогою:

    sudo touch /etc/noautoreboot
    
  • Його можна видалити за допомогою:

    sudo rm /etc/noautoreboot
    
  • Зауважте, важливо, чи існує файл чи ні , а не те, що він містить.

  • Якщо перезавантаження заплановане, а користувачів попереджено, тоді файл буде створений, (негайно майбутнє) перезавантаження все одно відбудеться.

  • Як це працює? Він використовує коротке замикання - оцінено або operator ( ||) як скорочення для:

    Якщо /etc/noautoreboot його немає, запустіть shutdown -r +5.

    Ця відповідь пояснює, як можуть працювати коротке замикання та та / або оператори if- thenлогіка. Для короткого, інтуїтивного та дуже неформального пояснення ви можете прочитати команду таким чином:

    /etc/noautorebootіснує! Або біжи shutdown -r +5.

    Дивіться, man [щоб побачити, як виконується сам тест.


12

Я люблю це робити, повідомляючи менеджеру сесій, що ми хочемо перезавантажити. Це можна зробити без кореневих дозволів, і ми отримаємо гарне вікно, яке попереджає нас про те, що система перезавантажиться, - навіть якщо ми захочемо, ми можемо скасувати перезавантаження.

Графічний шлях - кращий метод

Встановити gnome-scheduleз програмного центру Ubuntu. Якщо ви не хочете встановлювати нічого додаткового, зробіть це термінальним шляхом.

Відкрийте gnome-scheduleтире, створіть нове повторне завдання та встановіть наступні параметри:

  • Опис: Що б ви хотіли
  • Команда: dbus-send --print-reply --dest="org.gnome.SessionManager" /org/gnome/SessionManager org.gnome.SessionManager.Reboot
  • Виберіть X Application трохи нижче команди.
  • Час і дата, додатково:
    • Хвилина: 0,30

Залиште інші параметри за замовчуванням. Клацніть на Додати .


Термінальний шлях - не потрібно додаткового програмного забезпечення

Запустити з терміналу:

crontab -e

Додати цей рядок:

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

Зберегти та вийти. Припускаючи, що ви використовуєте nano(за замовчуванням), натисніть Ctrl + o та Ctrl + x .

Зауважте, що це не спрацює, якщо DISPLAY насправді відрізняється від цього :0, і саме тому цей метод не є кращим. Але, чесно кажучи, якщо ви перезавантажуєте комп'ютер кожні 30 хвилин, ваш DISPLAY, швидше за все, завжди буде :0.

Не використовуєте Gnome чи Unity?

Обидва способи, пояснені вище, залежать від деяких компонентів gnome, знайдених як на сесіях Gnome, так і на Unity. Якщо ви хочете зробити це в інших середовищах (наприклад, KDE Kubuntu, LXDE Kubuntu ...), замість цього команду замініть на цю:

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

Це не вимагає підтвердження, і перезапуститься негайно, але буде працювати у всіх середовищах, якщо, звичайно, ви не видалили ConsoleKit вручну.


6

Запустіть sudo crontab -eз командного рядка і додайте цей рядок у файл:

0,30 * * * * reboot

Це говорить системі запускати команду rebootкожні 30 хвилин як root. Огляд синтаксису часу див. Тут: http://linuxmoz.com/crontab-syntax-tutorial/


3
Це не спрацює, як це rebootпотрібно запустити root, і це додасть його до особистої crontab користувача, тому він запускається як той, хто не є кореневим користувачем. (Те ж саме з не sudo rebootбуде також працювати, тому що sudoбуде намагатися запросити пароль і помилка.) Для цього /etc/crontabслід використовувати це (будь ласка, зверніть увагу, що його синтаксис трохи інший).
Елія Каган

1
Ви можете оформити, sudo crontab -eа потім створити запис крона.
Тасс

-3

Використовуйте cronдля планування роботи кожні 30 хвилин. Направте цю роботу на сценарій оболонки, який просто є

reboot

в цьому.

Оскільки cronпрацює як root, вам не потрібно робити нічого особливого з точки зору дозволів.

Оновлення

Так, я насправді я ніколи в жодній із моїх систем не дозволяю користувальницьким crontabs (Є кращі способи, що дозволяють користувачам виконувати заплановані завдання на рівні користувача). Cron був створений з самого початку виключно для автоматизації системи, а не для користувачів, щоб планувати звичайні завдання. Такі речі, як обертання журналів (що відбувається і сьогодні)

Перезавантажувати ОБОВ'ЯЗКОВО слід запускати як root для коректної роботи, альтернативою є встановлення його липкого біту, так що при запуску як звичайний користувач він фактично виконує як root і працює так, як очікувалося, але при цьому відкриваючи ваш сервер до дозволення регулярного користувачі перезавантажують його за бажанням.

Ви навіть можете автоматизувати виклик до SUDO, але мені потрібно перекопатися до цього, не впевнений, чи можете ви автоматизувати необхідність пароля за допомогою SUDO (я не використовую його часто, я вважаю за краще просто перейти до кореня оболонки за допомогою SU)

Якщо ви встановите це в crontab системи, тоді все запускається як root, тому моє твердження є точним (я просто нехтував зазначенням, що слід використовувати систему широкого рівня)

Що стосується вашого запитання "Навіщо це загортати в сценарій?" ну чому б ні? Якщо ОП поміщає його в сценарій оболонки, то в якийсь момент в майбутньому його потрібно додати, він просто додає до сценарію, замість того, щоб відкривати crontab, щоб знайти завдання, видалити його, замінити його на сценарій оболонки, потім напишіть сценарій зі старим + новим в.

Протягом 20 років як Sys Admin / Developer працював із системами, як Ultrix / Solaris, і навіть VAX навчив мене одне головне.

Якщо ви можете спростити це на початку, то це залишається легким, оскільки це час життя.

Я дійсно не сприймаю такого "мінімалістичного" ставлення, яке має багато адміністраторів сучасних систем, де робити якомога менше є запорукою успіху. Більшість серверів сьогодні легко в 20 разів + потужніші за все, що я коли-небудь розпочав, і такий сценарій (загортання в сценарії оболонок) був рекомендований тоді практикою, тому насправді немає аргументів, щоб цього не робити.

Якщо ви дійсно не хочете перейти на хардкор Unix / Linux, у такому випадку позначайте все це на вході в cron і передайте все разом так, як це слід зробити :-)

Однак я роблю відступ, а також розумію, що багато хлопців сьогодні кидаються на глибокий кінець і говорять змусити роботу працювати, тому що їм не вистачає часу (і, як правило, схильності) сісти і вивчити нові методи (або старого в цьому випадку) або навіть хочуть пограти з цими речами поза роботою.

У мене особисто є один сервер серед тих, що я запускаю, присвячений виключно для мене, щоб грати, тому я можу перевірити такі речі ... що краще A або B, тому я не без підстав радити будь-який із це.


Дивіться моє оновлення .. Ви можете повернути мені 1 бал назад, якщо хочете ;-)
shawty

Спробуйте ще раз ... будьте терплячі ...
shawty

2
Це зараз вже не відповідь! (Крім того, ви плутаєте липкий шматочок і встановлений біт .)
Елія Каган

Так, це відповідь, я її набрав, додав як відповідь, тому це відповідь !!!
shawty
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.