Jestem tylko ciekawy: jaki może być cel restartowania co 30 minut?
Rafał Cieślak
Odpowiedzi:
30
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:
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:
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.
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:
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:
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.
To nie zadziała, ponieważ rebootmusi być uruchomione jako root, a to dodaje go do osobistego crontab użytkownika, więc działa jako użytkownik inny niż root. (To samo z nie sudo rebootbędzie również działać, ponieważ sudospróbuje poprosić o podanie hasła i nie powiedzie się.) /etc/crontabNależy zamiast tego użyć do tego (pamiętaj, że jego składnia jest nieco inna).
Eliah Kagan
1
Możesz wydać, sudo crontab -ea następnie utworzyć pozycję cron.
Tass
-3
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.
Odpowiedzi:
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 zaplanowanieshutdownpolecenia, aby ostrzegało użytkownika.Aby zaplanować wyłączenie co pół godziny z ostrzeżeniem 5 minut wcześniej, dodaj to do
/etc/crontab:W rzeczywistości nie musisz dodawać linii pięści, która jest komentarzem. Zawarłem to dla jasności - coś takiego już tam jest.
-r) pięć minut po (+5) uruchomieniu polecenia. Działa co pół godziny (*/30). Zobaczman croniman 5 crontab.+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ć*/20lub0,20,40.)/sbinznajduje się wPATHzmiennej określonej w górnej części/etc/crontab. W przeciwnym razieshutdown(undercommand) 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.
sudo shutdown -c.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. (Polecamanacrondo 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:
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ą:
Można go usunąć za pomocą:
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: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:Zobacz,
man [jak przeprowadzany jest sam test.źródło
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:dbus-send --print-reply --dest="org.gnome.SessionManager" /org/gnome/SessionManager org.gnome.SessionManager.RebootPozostaw pozostałe opcje na wartościach domyślnych. Kliknij Dodaj .
Terminal Way - nie ma potrzeby instalowania dodatkowego oprogramowania
Uruchom z terminala:
Dodaj tę linię:
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:
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.
źródło
Uruchom
sudo crontab -ez wiersza poleceń i dodaj ten wiersz do pliku:0,30 * * * * rebootTo 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/źródło
rebootmusi być uruchomione jakoroot, a to dodaje go do osobistego crontab użytkownika, więc działa jako użytkownik inny niż root. (To samo z niesudo rebootbędzie również działać, ponieważsudospróbuje poprosić o podanie hasła i nie powiedzie się.)/etc/crontabNależy zamiast tego użyć do tego (pamiętaj, że jego składnia jest nieco inna).sudo crontab -ea następnie utworzyć pozycję cron.Służy
crondo planowania pracy co 30 minut. Skieruj to zadanie na skrypt powłoki, który po prostu maw 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.
źródło