Chciałbym zaplanować ponowne uruchomienie mojego Ubuntu co 30 minut. Czy jest jakieś polecenie lub graficzny sposób na zrobienie tego?

Najlepszy sposób na zrobienie tego zależy od tego , dlaczego chcesz, aby Ubuntu uruchamiał się co pół godziny.

^{Dlatego zalecam edycję pytania, aby wyjaśnić, dlaczego chcesz to zrobić.}

Ponowne uruchamianie co 30 minut i ostrzeganie użytkowników przed każdym ponownym uruchomieniem:

Zakładając, że ludzie mogą korzystać z maszyny, lokalnie lub zdalnie, najlepiej unikać ponownego uruchamiania Ubuntu spod nich bez żadnego ostrzeżenia. Dlatego zamiast planować rebootpolecenie, zalecam zaplanowanie shutdownpolecenia, aby ostrzegało użytkownika.

Aby zaplanować wyłączenie co pół godziny z ostrzeżeniem 5 minut wcześniej, dodaj to do /etc/crontab:

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

^{W rzeczywistości nie musisz dodawać linii pięści, która jest komentarzem. Zawarłem to dla jasności - coś takiego już tam jest.}

• Spowoduje to zaplanowanie wyłączenia systemu w celu ponownego uruchomienia ( -r) pięć minut po ( +5) uruchomieniu polecenia. Działa co pół godziny ( */30). Zobacz man croni man 5 crontab.
• Zmień +5na coś innego, aby zmienić czas, przez jaki użytkownicy zostali ostrzeżeni o ponownym uruchomieniu.
• 0,30pod minutą będzie również działać, jeśli wolisz. (Podobnie, gdyby to było co 20 minut, możesz napisać */20lub 0,20,40.)
• Upewnij się, że /sbinznajduje się w PATHzmiennej określonej w górnej części /etc/crontab. W przeciwnym razie shutdown(under command) będzie musiało zostać wywołane jako /sbin/shutdown.

Polecenie będzie zawsze uruchamiane po upływie pół godziny, jeśli maszyna jest uruchomiona w tym czasie . Spowoduje to, że wyłączenia będą ogłaszane co pół godziny i będą wykonywane o 5 minutach i 35 minutach po godzinie.

• Jedną z korzyści jest to, że administrator może anulować właśnie ogłoszone zamknięcie za pomocą sudo shutdown -c.
• Jeśli komputer nie działa w określonym czasie, gdy zaplanowane polecenie ma zostać uruchomione, nie zostanie uruchomione. Jeśli nie jest to adekwatne do twoich potrzeb, będziesz musiał zaplanować ponowne uruchomienie w inny sposób. (Nie jest to specyficzne dla użycia, shutdownale miałoby zastosowanie w równym stopniu, jeśli planowałeś reboot.) W takim przypadku edytuj swoje pytanie, aby wyjaśnić swoje szczególne potrzeby. (Polecam anacrondo tego, ale twoje przedziały czasowe są zdecydowanie za krótkie).

Ułatwienie administratorom w ogóle zapobiegania automatycznym restartom:

Możesz to skonfigurować, aby administrator mógł łatwo zawiesić wszystkie automatycznie zaplanowane ponowne uruchomienie:

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

Te rozkłady restartuje ten sam sposób - co pół godziny, a pięć minut ostrzeżenie - poza tym, że nie będzie zaplanować restart jeśli plik o nazwie noautorebootistnieje /etc.

• Ten plik kontrolny może zostać utworzony przez administratora za pomocą:

  sudo touch /etc/noautoreboot
  

• Można go usunąć za pomocą:

  sudo rm /etc/noautoreboot
  

• Pamiętaj, że liczy się to, czy plik istnieje , a nie co zawiera.

• Jeśli ponowne uruchomienie jest zaplanowane, a użytkownicy są ostrzegani, następnie plik jest tworzony, The (natychmiast zbliżający) restart będzie nadal występować.

• Jak to działa? Używa skrótu zwartego lub operatora ( ||) jako skrótu dla:

  Jeśli /etc/noautoreboot nie istnieje, uruchom shutdown -r +5.

  Ta odpowiedź wyjaśnia, jak mogą działać zwarcia i / lub operatorzy if- thenlogika. Aby uzyskać krótkie, intuicyjne i bardzo nieformalne wyjaśnienie, możesz przeczytać polecenie w ten sposób:

  /etc/noautorebootistnieje! Lub biegnij shutdown -r +5.

  Zobacz, man [jak przeprowadzany jest sam test.

Uwielbiam to robić, mówiąc Menedżerowi sesji, że chcemy zrestartować komputer. Można to zrobić bez uprawnień roota, a my otrzymujemy ładne okno, które ostrzega nas, że system zostanie zrestartowany - nawet jeśli możemy anulować restart.

Metoda graficzna - preferowana metoda

Zainstaluj gnome-schedulez Centrum oprogramowania Ubuntu. Jeśli nie chcesz instalować niczego dodatkowego, zrób to Terminal Way.

Otwórz gnome-schedulez myślnika, utwórz nowe powtarzające się zadanie i ustaw następujące opcje:

• Opis: Cokolwiek chcesz
• Komenda: dbus-send --print-reply --dest="org.gnome.SessionManager" /org/gnome/SessionManager org.gnome.SessionManager.Reboot
• Wybierz X Aplikacja tuż pod poleceniem.
• Data i godzina, zaawansowane:
  • Minuta: 0,30

Pozostaw pozostałe opcje na wartościach domyślnych. Kliknij Dodaj .

Terminal Way - nie ma potrzeby instalowania dodatkowego oprogramowania

Uruchom z terminala:

crontab -e

Dodaj tę linię:

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

Wyjście bezpieczeństwa. Zakładając, że używasz nano(domyślny), naciśnij Ctrl + o i Ctrl + x .

Pamiętaj, że to nie zadziała, jeśli Twój WYŚWIETLACZ różni się od :0tego i dlatego ta metoda nie jest preferowana. Ale szczerze mówiąc, jeśli restartujesz komputer co 30 minut, DISPLAY najprawdopodobniej zawsze będzie :0.

Nie używasz Gnome lub Unity?

Obie metody wyjaśnione powyżej zależą od niektórych składników gnome, znalezionych zarówno podczas sesji Gnome, jak i Unity. Jeśli chcesz to zrobić w innych środowiskach (takich jak KDE Kubuntu, LXDE Kubuntu ...) lepiej zastąp zamiast tego polecenie:

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

To nie poprosi o potwierdzenie i uruchomi się natychmiast, ale będzie działać we wszystkich środowiskach, zakładając, że oczywiście nie odinstalowałeś ConsoleKit.

Uruchom sudo crontab -ez wiersza poleceń i dodaj ten wiersz do pliku:

0,30 * * * * reboot

To mówi systemowi, aby uruchamiał polecenie rebootco 30 minut jako root. Aby zapoznać się ze składnią czasu, zobacz tutaj: http://linuxmoz.com/crontab-syntax-tutorial/

Służy crondo planowania pracy co 30 minut. Skieruj to zadanie na skrypt powłoki, który po prostu ma

reboot

w tym.

Ponieważ crondziała jako root, nie powinieneś robić nic specjalnego pod względem uprawnień.

Aktualizacja

Tak, w rzeczywistości nigdy w żadnym z moich systemów nie zezwalam na crontabs oparte na użytkownikach (istnieją lepsze sposoby pozwalania użytkownikom na wykonywanie zaplanowanych zadań na poziomie użytkownika) cron został zaprojektowany od samego początku wyłącznie w celu automatyzacji systemu, a nie dla użytkowników, aby planowali zwykłe zadania Rzeczy takie jak rotacje kłód (które wciąż się zdarzają do dziś)

Ponowne uruchomienie MUSI być uruchamiane jako root, aby działało poprawnie, alternatywnie jest ustawienie jego lepkości, aby podczas uruchamiania jako zwykły użytkownik faktycznie działał jako root i działał zgodnie z oczekiwaniami, ale w ten sposób otwierasz serwer, umożliwiając regularne użytkownicy będą go ponownie uruchamiać do woli.

Możesz nawet zautomatyzować połączenie z SUDO, ale muszę się w to zagłębić, nie jestem pewien, czy możesz zautomatyzować potrzebę hasła za pomocą SUDO (nie używam go często, wolę po prostu spaść prosto do roota powłoka przy użyciu SU)

Jeśli ustawisz go w crontabie systemowym, wszystko jest uruchamiane jako root, więc moje stwierdzenie jest dokładne (po prostu zapomniałem wspomnieć, że należy użyć systemowego)

Co do twojego pytania „Po co zawijać go w skrypt?” czemu nie? Jeśli OP umieści go w skrypcie powłoki, to w pewnym momencie w przyszłości będzie musiał go dodać, po prostu dodaje do skryptu, zamiast otwierać crontab, zlokalizować zadanie, usunąć go, zastąpić skryptem powłoki, następnie napisz skrypt ze starym + nowym w.

Ponad 20 lat pracy jako administrator / programista Sys pracujący z systemami już od czasów Ultrix / Solaris, a nawet VAX nauczyło mnie jednej ważnej kwestii.

Jeśli możesz to ułatwić na początku, pozostanie to łatwe do końca życia.

Naprawdę nie rozumiem tego „minimalistycznego” podejścia, jakie ma wielu współczesnych administratorów systemów, gdzie robienie jak najmniej jest kluczem do sukcesu. Większość serwerów w dzisiejszych czasach jest z łatwością ponad 20 razy mocniejsza niż cokolwiek, na czym zaczynałem, i tego rodzaju scenariusz (zawijanie skryptów powłoki) był wtedy zalecaną praktyką, więc naprawdę nie ma argumentów, by tego nie robić.

Chyba że naprawdę chcesz wybrać hardcorowy system Unix / Linux, w którym to przypadku oznacz to wszystko we wpisie crona i połącz wszystko razem tak, jak powinno się to zrobić :-)

Jednak robię dygresję, a także rozumiem, że wielu facetów jest obecnie wrzuconych do głębokiego końca i kazano im działać, ponieważ nie mają czasu (i zazwyczaj skłonności), aby usiąść i poznać nowe techniki (lub stare w tym przypadku), a nawet chcesz bawić się tymi rzeczami poza pracą.

Osobiście mam jeden serwer spośród tych, które uruchamiam, który jest przeznaczony wyłącznie do zabawy, więc mogę przetestować takie rzeczy ... co jest lepsze A lub B, więc nie bez powodu doradzam którekolwiek z nich to.