Obecnie próbuję zrozumieć różnicę między init.dcron a @rebooturuchamianiem skryptu podczas uruchamiania / uruchamiania systemu.

Użycie @reboot(ta metoda została wspomniana na tym forum przez hs.chandra ) jest nieco prostsze, po prostu wchodząc crontab -ei tworząc a, @reboot /some_directory/to_your/script/your_script.txta następnie your_script.txtbędzie wykonywane przy każdym ponownym uruchomieniu systemu. Szczegółowe wyjaśnienie @rebootznajduje się tutaj

Alternatywnie, osadzając /etc/init.d/your_script.txtw drugiej linii skryptu, tj .:

#!/bin/bash
# /etc/init.d/your_script.txt

Możesz uruchomić, chmod +x /etc/init.d/your_script.txtco powinno również skutkować your_script.txturuchomieniem przy każdym uruchomieniu systemu.

P1: Jakie są kluczowe różnice między nimi?
P2: Który jest bardziej niezawodny?
P3: Czy jest lepszy z tych dwóch?
P4: Czy to jest właściwy sposób osadzania skryptu, który ma być uruchamiany podczas uruchamiania?

Będę zawierać plik .sh bash, który będzie uruchamiany podczas uruchamiania.

init.d, znany również jako skrypt SysV, ma na celu uruchamianie i zatrzymywanie usług podczas inicjowania i zamykania systemu. ( /etc/init.d/skrypty są również uruchamiane w systemach obsługujących systemd w celu zapewnienia zgodności).

• Skrypt jest wykonywany podczas rozruchu i zamykania systemu (domyślnie).
• Skrypt powinien być skryptem init.d, a nie tylko skryptem. Powinien wspierać starti stopwiele więcej (zobacz zasady Debiana )
• Skrypt można wykonać podczas uruchamiania systemu (możesz określić, kiedy).

crontab(i dlatego @reboot).

• cron wykona każde zwykłe polecenie lub skrypt, nic specjalnego tutaj.
• każdy użytkownik może dodać @rebootskrypt (nie tylko root)
• w systemie Debian z systemd: @reboot crona jest wykonywany podczas multi-user.target.
• w systemie Debian z SysV (nie systemd) wspomina crontab (5): Pamiętaj, że uruchomienie, jeśli chodzi o @reboot, to czas uruchamiania demona cron (8). W szczególności może to nastąpić przed uruchomieniem niektórych demonów systemu lub innych obiektów. Wynika to z sekwencji kolejności rozruchu maszyny.
• łatwe jest zaplanowanie tego samego skryptu przy rozruchu i okresowo.

/etc/rc.localjest często uważany za brzydki lub przestarzały (przynajmniej przez redhat ), wciąż ma kilka fajnych funkcji:

• rc.local wykona każde zwykłe polecenie lub skrypt, nic specjalnego tutaj.
• w systemie Debian z SysV (nie systemd): rc.localbyła (prawie) ostatnia usługa do uruchomienia.
• ale w systemie Debian z systemd: rc.localjest wykonywany network.targetdomyślnie po (nie network-online.target!)

Jeśli chodzi o systemd network.targeti network-online.target, przeczytaj Uruchamianie usług po uruchomieniu sieci .

Po pierwsze, należy wyjaśnić:

• init.d to katalog przechowujący skrypty kontrolne usług, które kontrolują uruchamianie i zatrzymywanie usług takich jak httpdlubcron
• rc.local to usługa, która pozwala na uruchamianie dowolnych skryptów w ramach procesu uruchamiania systemu

Pod względem tego, czy lepiej używać, rc.localczy cronuruchamiać skrypt, podejrzewam, że jest to bardziej kwestia estetyki niż praktyczności. cron, jako harmonogram zadań, ma służyć jako metoda przeprowadzania konserwacji lub konserwacji komputera, na przykład sprawdzania aktualizacji, czyszczenia pamięci podręcznej lub przeprowadzania audytów bezpieczeństwa. Nie oznacza to, że ogranicza się do wykonywania tych funkcji, ponieważ może uruchomić dowolny skrypt lub polecenie o określonej porze (np. @reboot).

rc.localZ drugiej strony użycie bardziej odpowiadałoby zadaniu typu konfiguracji systemu, ponieważ rc.localwykonywane przez system inicjujący maszyny jest zazwyczaj odpowiedzialne za ustawienie konfiguracji sieci, usług lub środowisk maszyny (ale znowu nie jest ograniczone tylko do to zadanie).

Oba te punkty należy jednak złagodzić faktem, że nie wszystkie systemy inicjujące oferują rc.localmechanizm i nie wszystkie demony cron oferują @rebootznacznik psuedo.

Punkty bonusowe

Jak wspomniano, init.dkatalog zawiera skrypty sterujące usługami, które można uruchomić lub zatrzymać w systemie (przynajmniej na komputerach korzystających z SysVsystemu typu init). W zależności od systemu init i celu skryptu rozsądne może być przekonwertowanie skryptu na skrypt init, który będzie uruchamiany w taki sam sposób jak usługa. Jest to jednak w dużym stopniu zależne od systemu init, ponieważ struktura otaczająca sposób tworzenia tych plików może się znacznie różnić.

Ostatnie słowo

Należy również zauważyć, że zazwyczaj skrypty bash kończą się sufiksem .shzamiast .txt, ponieważ natychmiast oznacza to, że plik jest skryptem powłoki zamiast pliku tekstowego. Biorąc to pod uwagę, pod warunkiem, że albo ma shebang ( #!/bin/bash) u góry pliku, albo jest wywoływane jako bash /path/to/script.whatever, nie powinno mieć znaczenia pod względem wykonywania skryptu.

Piszę swoją odpowiedź poniżej;

P1: Jakie są kluczowe różnice między nimi?

Oprócz różnic wspomnianych przez innych użytkowników powyżej, chciałbym podkreślić, że @reboot jest zależny od demona crond. Jesteś zależny od kolejności uruchamiania crond. Chociaż większość przypadków, crond zaczyna się dobrze, ale czasem może się nie powieść (przynajmniej widziałem pewne awarie w niektórych moich projektach). Podczas pisania skryptu inicjującego błąd zwykle występuje, jeśli zrobisz coś złego w skrypcie (np. Poleganie na usłudze, która uruchomi się po Twojej usłudze)

P2: Który jest bardziej niezawodny?

W oparciu o powyższe myślę, że init jest bardziej niezawodny. Ale jest jeszcze jeden punkt wspomniany przez „Franklin Piat” w pierwszej odpowiedzi. Zwykle potrzebujesz skryptu inicjującego dla demona i powinieneś przestrzegać zasad

P3: Czy jest lepszy z tych dwóch?

Nie sądzę (lokalna wersja językowa jest trochę stara i przestarzała)

P4: Czy to jest właściwy sposób osadzania skryptu, który ma być uruchamiany podczas uruchamiania?

Tak. Zwykle pisarze aplikacji / pakietów robią w ten sposób.