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.