Jak mogę uruchamiać skrypty automatycznie podczas uruchamiania systemu Ubuntu, aby nie trzeba było uruchamiać ich ręcznie po uruchomieniu?

W zależności od rodzaju skryptów, które musisz uruchomić. W przypadku usług i tym podobnych powinieneś użyć upstart . Ale dla skryptu użytkownika powinny one być uruchamiane jako skrypty sesji przez gnome! Zajrzyj do System> Preferencje> Aplikacje startowe.

Na marginesie, jeśli potrzebujesz skryptów, które będą uruchamiane przy logowaniu do terminala, możesz dodać je do pliku .bash_login w twoim katalogu domowym.

Dla 14.04 i starszych

Proste polecenie (takie, które nie musi pozostawać uruchomione) może użyć zadania Upstart, takiego jak:

start on startup
task
exec /path/to/command

Zapisz to w .confpliku w /etc/init(jeśli potrzebujesz, aby działał jako root podczas uruchamiania systemu) lub w ~/.config/upstart(jeśli potrzebujesz, aby działał jako użytkownik podczas logowania).

Jednym z podejść jest dodanie zadania cron @reboot :

1. Uruchomienie crontab -epozwoli ci na edycję twojego crona.

2. Dodanie do niego takiej linii:

   @reboot /path/to/script
   

   wykona ten skrypt po uruchomieniu komputera.

Co powiesz na dodanie polecenia /etc/rc.local? będziesz musiał użyć dostępu sudo, aby edytować ten plik.

sudo nano /etc/rc.local

W przypadku wersji 15.04 i nowszych:

Aby uruchomić (krótkotrwałe) polecenie ¹ przy uruchomieniu systemd, możesz użyć systemowej jednostki typu OneShot. Na przykład utwórz /etc/systemd/system/foo.servicezawierające:

[Unit]
Description=Job that runs your user script

[Service]
ExecStart=/some/command
Type=oneshot
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Następnie uruchomić:

sudo systemctl daemon-reload
sudo systemctl enable foo.service

Zasadniczo jest to po prostu konwersja typowego zadania Upstart na systemowe (patrz Systemd dla użytkowników Upstart ).

Możesz uruchomić wiele poleceń z tego samego pliku usługi, używając wielu ExecStartwierszy:

[Service]
ExecStart=/some/command
ExecStart=/another/command some args
ExecStart=-/a/third/command ignore failure

Polecenie należy zawsze podawać z pełną ścieżką. Jeśli dowolne polecenie nie powiedzie się, pozostałe nie zostaną uruchomione. -Przed ścieżką opowiada Systemd ignorować status wyjścia niezerową (zamiast uznając je awarii).

Istotnych:

• Archuj wpis Wiki na systemd
• man 5 systemd.service

W przypadku sesji użytkownika możesz ~/.config/systemdzamiast tego utworzyć jednostkę systemową . Powinno to działać od 16.04 r., Ale nie we wcześniejszych wersjach Ubuntu z systememd (ponieważ te nadal używały Upstart do sesji użytkowników). Jednostkami sesji użytkownika można sterować za pomocą tych samych poleceń, co w przypadku usług systemowych, ale z --userdodaną opcją:

systemctl --user daemon-reload
systemctl --user status foo.service

Składnia powłoki

Zauważ, że w przeciwieństwie do Upstart, systemd nie uruchamia Exec*poleceń przez powłokę. Wykonuje pewne ograniczone rozszerzanie zmiennych i wiele poleceń (oddzielonych przez ;), ale to tyle, jeśli chodzi o składnię podobną do powłoki. W przypadku czegoś bardziej skomplikowanego, na przykład przekierowania lub potoki, wpisz polecenie w sh -c '...'lub bash -c '...'.

¹ W przeciwieństwie do długowiecznych demonów.

Istnieją różne sposoby automatycznego uruchamiania poleceń:

1. Dorobkiewicz system będzie wykonać wszystkie skrypty z której znajdzie konfigurację w katalogu /etc/init. Skrypty te będą uruchamiane podczas uruchamiania systemu (lub w odpowiedzi na pewne zdarzenia, np. Żądanie zamknięcia), a więc są miejscem uruchamiania poleceń, które nie wchodzą w interakcje z użytkownikiem; wszystkie serwery są uruchamiane przy użyciu tego mechanizmu.

   Możesz znaleźć czytelne wprowadzenie do: http://upstart.ubuntu.com/getting-started.html strony podręcznika użytkownika man 5 initi man 8 initpodać pełne szczegóły.

2. Skrypt powłoki nazwany .gnomercw katalogu domowym jest automatycznie pozyskiwany przy każdym logowaniu do sesji GNOME. Możesz tam wstawiać dowolne polecenia; zmienne środowiskowe ustawione w tym skrypcie będą widoczne dla każdego programu uruchomionego w sesji.

   Pamiętaj, że sesja nie rozpoczyna się, dopóki .gnomercskrypt nie zostanie zakończony; dlatego jeśli chcesz automatycznie uruchomić jakiś długo działający program, musisz dołączyć &do wywołania programu, aby odłączyć go od działającej powłoki.

3. Opcja menu System -> Preferencje -> Aplikacje startowe pozwala określić, które aplikacje powinny być uruchamiane po rozpoczęciu sesji graficznej (Ubuntu predefiniuje całkiem sporo) oraz dodawać lub usuwać je według własnego gustu. Ma to prawie ten sam cel i zakres .gnomercskryptu, z tym wyjątkiem, że nie musisz znać shskładni (ale nie możesz też użyć żadnej shkonstrukcji programowej).

$HOME/.config/autostart

• Ta lokalizacja zawiera listę aplikacji startowych.
• .desktop tutaj można umieścić plik, który zostanie wykonany przy uruchomieniu.

Przykładowy .desktopplik:

Wstawianie i podawanie następującego .desktoppliku :$HOME/.config/autostartchmod +x

[Desktop Entry]
Type=Application
Exec="</path/to/script>"
Hidden=false
NoDisplay=false
X-GNOME-Autostart-enabled=true
Name=Startup Script

Tutaj "</path/to/script>"jest zastąpiony ścieżką do twojego script.sh
(zwykle zalecane, aby /usr/local/binmożna go było wykonać bezpośrednio poleceniem powiedz myscriptzastąpiony "</path/to/script>").

Przykładowy przykład script.sh:

#!/bin/bash
<commands to be executed>
exit

Wynik: .desktopplik zostanie uruchomiony, z $HOME/.config/autostartktórego wykona skryptExec=

Dlatego możesz uruchomić żądany skrypt powłoki podczas uruchamiania!

Dla prostych rzeczy możesz dodać polecenie w System-> Preferencje-> Sesje wskazujące lokalizację twojego skryptu.

Alternatywnie możesz dodać go do /etc/init.d/rc.local lub zrobić upstart, jeśli jest to coś na niższym poziomie .

Więcej informacji na https://help.ubuntu.com/community/UbuntuBootupHowto

cron odpowiedź zaimplementowana inna niż najczęściej głosowana

Ta odpowiedź wciąż używa, cronale używa innej metody niż najczęściej głosowana odpowiedź. Działa to od wersji Ubuntu 16.04, ale prawdopodobnie jest obsługiwane znacznie wcześniej. Po prostu zacząłem używać crondo uruchamiania zadań, gdy komputer uruchamia się od 16.04.

Kiedy działa cron?

W komentarzach ktoś zapytał „kiedy oni biegną?”. Możesz powiedzieć w syslog / journalctl:

$ journalctl -b | grep cron
Jan 02 16:54:40 alien cron[919]: (CRON) INFO (pidfile fd = 3)
Jan 02 16:54:40 alien cron[919]: (CRON) INFO (Running @reboot jobs)
Jan 02 16:54:40 alien systemd[1]: Started Run anacron jobs.
Jan 02 16:54:40 alien anacron[949]: Anacron 2.3 started on 2018-01-02
Jan 02 16:54:40 alien anacron[949]: Normal exit (0 jobs run)
Jan 02 16:54:40 alien CRON[952]: pam_unix(cron:session): session opened for user root by (uid=0)
Jan 02 16:54:40 alien CRON[954]: pam_unix(cron:session): session opened for user root by (uid=0)
Jan 02 16:54:40 alien CRON[951]: pam_unix(cron:session): session opened for user root by (uid=0)
Jan 02 16:54:40 alien CRON[950]: pam_unix(cron:session): session opened for user root by (uid=0)
Jan 02 16:54:40 alien CRON[985]: (root) CMD (   /usr/local/bin/cron-reboot-cycle-grub-background)
Jan 02 16:54:40 alien CRON[954]: pam_unix(cron:session): session closed for user root
Jan 02 16:54:40 alien cron[919]: sendmail: Cannot open smtp.gmail.com:587
Jan 02 16:54:40 alien CRON[952]: pam_unix(cron:session): session closed for user root
Jan 02 16:54:40 alien cron[919]: sendmail: Cannot open smtp.gmail.com:587
Jan 02 16:54:40 alien CRON[950]: pam_unix(cron:session): session closed for user root

Jedną z rzeczy, na które należy zwrócić uwagę, jest cronwysłanie wiadomości e-mail o statusie uruchomionych zadań i @rebootzadań uruchomionych, aby wczesny menedżer sieci i poczta e-mail nie były uruchomione, chyba że wprowadzisz sleeppolecenie do skryptu (ów).

Gdzie umieścić swoje skrypty

Umieść swoje skrypty w katalogu /etc/cron.d:

$ ll /etc/cron.d
total 44
drwxr-xr-x   2 root root  4096 Nov 26 19:53 ./
drwxr-xr-x 139 root root 12288 Dec 31 13:58 ../
-rw-r--r--   1 root root   244 Dec 28  2014 anacron
-rw-r--r--   1 root root   148 Feb 18  2017 cycle-grub-background
-rw-r--r--   1 root root   138 Mar  5  2017 display-auto-brightness
-rw-r--r--   1 root root   460 Nov 26 19:53 nvidia-hdmi-sound
-rw-r--r--   1 root root   102 Feb  9  2013 .placeholder
-rw-r--r--   1 root root   224 Nov 19  2016 touch-vmlinuz
-rw-r--r--   1 root root   700 Aug  5 11:15 turn-off-hyper-threading

Jak wygląda skrypt?

Oto kilka skryptów skonfigurowanych do uruchamiania każdego rozruchu:

$ cat /etc/cron.d/cycle-grub-background SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin 
@reboot   root    /usr/local/bin/cron-reboot-cycle-grub-background

$ cat /etc/cron.d/touch-vmlinuz
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
@reboot   root    touch "/boot/vmlinuz-"`uname -r`

W tym celu powinieneś użyć upstart . Upstart jest używany w procesach Ubuntu, które są uruchamiane automatycznie. Jest to ulepszone rozwiązanie, takie jak stare skrypty init.d System-V. Pozwala także na wprowadzenie wstępnych warunków do uruchomienia skryptu (tj. Czy potrzebujesz sieci działającej? Itp.)