Dlaczego polecenie w /etc/rc.local nie jest wykonywane podczas uruchamiania?

W /etc/rc.localskrypcie mam jedno polecenie, które ma uruchomić demona aktualizacji Tiny Tiny RSS podczas uruchamiania, ale skrypt nie jest uruchamiany podczas uruchamiania. Czemu?

Cały plik /etc/rc.local:

#!/bin/sh -e
#
# rc.local
#
# This script is executed at the end of each multiuser runlevel.
# Make sure that the script will "exit 0" on success or any other
# value on error.
#
# In order to enable or disable this script just change the execution
# bits.
#
# By default this script does nothing.

/sbin/start-stop-daemon -b -c www-data:www-data -S -x /usr/bin/php /var/www/ttrss/update_daemon2.php -- -quiet

exit 0

/etc/rc.local jest wykonywalny:

# ls -l /etc/rc.local
-rwxr-xr-x 1 root root 342 May 25 16:14 /etc/rc.local

/etc/init.d/rc.local istnieje i jest wykonywalny:

# ls -l /etc/init.d/rc.local
-rwxr-xr-x 1 root root 801 Jul 27  2012 /etc/init.d/rc.local

/etc/init.d/rc.local ma być wykonywany podczas uruchamiania dla tego poziomu pracy:

# runlevel 
N 2
# ls -l /etc/rc2.d/S99rc.local 
lrwxrwxrwx 1 root root 18 Sep 22  2012 /etc/rc2.d/S99rc.local -> ../init.d/rc.local

Jeśli ręcznie wywołam plik /etc/rc.local z wiersza polecenia, ładuje się demon update_daemon ...

# /etc/rc.local
# ps ax | grep update_daemon2.php
2233 ?        S      0:00 /usr/bin/php /media/sda5/www/news/update_daemon2.php -quiet
2234 ?        S      0:00 /usr/bin/php /media/sda5/www/news/update_daemon2.php -quiet

... co muszę pamiętać za każdym razem, gdy mój serwer uruchamia się ponownie, dopóki problem nie zostanie rozwiązany.

Podobne pytania już istnieją, ale jak dotąd nie byłem w stanie zastosować informacji zawartych w moim konkretnym problemie.

Dlaczego komenda w rc.local nie jest wykonywana podczas uruchamiania?

rc.localskrypt kończy działanie, jeśli wystąpi jakikolwiek błąd podczas wykonywania któregokolwiek z jego poleceń (wspomnij o -eflagi w #!/bin/sh -e).

Możliwe, że niektóre warunki wstępne nie są spełnione, gdy próbujesz uruchomić swoje polecenia, gdy rc.localwykonanie ma miejsce, więc wykonanie polecenia nie powiedzie się.

Zetknąłem się z tym samym podczas ręcznego ustawiania gubernatora procesora, ale nie robiłem tego w rc.local. Oto moje niestandardowe obejście, które update-rc.dpozwala na uruchamianie poleceń podczas uruchamiania:

1. Utwórz plik myscript.shw katalogu /etc/init.dz nagłówkiem:#!/bin/sh
2. Umieść niestandardowe polecenia jako treść
3. Spraw, by był wykonywalny: sudo chmod +x /etc/init.d/myscript.sh
4. Utwórz dowiązania symboliczne dla swojego skryptu dla różnych poziomów uruchamiania: sudo update-rc.d myscript.sh defaults

Możesz także sprawdzić /etc/network/if-up.dskrypty i sprawdzić, czy możesz uruchamiać polecenia podczas uruchamiania sieci.

miałem podobny problem w rc.local, który nie uruchamiał się przy starcie

sshades dostarczyło mi następującą odpowiedź:

Ubuntu używa teraz systemd, a rc.local jest teraz uważany za usługę, która jest domyślnie wyłączona. Możesz włączyć rc.local „on”, wprowadzając następujące polecenie i ponownie uruchamiając:

sudo systemctl enable rc-local.service

https://askubuntu.com/a/770033/395498

chociaż nie przetestowałem jego rozwiązania, myślę, że brzmi to logicznie i zadziała. Jednak :

Znalazłem również rozwiązanie, które załatwi dodanie skryptu do ./.config/autostart-scripts/

spróbuj sudo sysv-rc-confi sprawdź, czy rc.localjest włączony

rc.local         [ ]   [x]   [x]   [x]   [x]   [ ]   [ ]   [ ]

Upewnij się, że skrypt rc.local jest wykonywalny:

sudo chmod +x /etc/rc.local

Następnie włącz:

sudo systemctl enable rc-local.service

Uruchom ponownie system lub uruchom skrypt ręcznie, uruchamiając:

sudo systemctl start  rc-local.service

Status usługi można wyświetlić, uruchamiając:

$ sudo systemctl status rc-local.service
● rc-local.service - /etc/rc.local Compatibility
   Loaded: loaded (/lib/systemd/system/rc-local.service; static; vendor preset: enabled) 
Drop-In: /lib/systemd/system/rc-local.service.d
           └─debian.conf
   Active: active (running) since Mon 2018-04-02 10:39:44 -03; 1s ago
  Process: 2044 ExecStart=/etc/rc.local start (code=exited, status=0/SUCCESS)
 Main PID: 2049 (svscanboot)
Tasks: 3
 Memory: 556.0K
CPU: 10ms
CGroup: /system.slice/rc-local.service

Ten problem występował na niektórych serwerach hostowanych podczas ładowania reguł FW.

Na tych polach bardzo szybko się restartują i znaleźliśmy po prostu „uśpienie 1” w rc.local, zanim instrukcje load wydają się rozwiązać problem. Wydaje mi się, że dawało to trochę czasu na założenie interfejsów przed załadowaniem reguł FW.

Kiedyś edytowałem za rc.localpomocą Notatnika w systemie Windows i zaczął mieć ten problem.

W takim przypadku użycie edytora tekstu obsługuje konwersję EOL, taką jak Notepad ++, w celu konwersji stylu EOL na „Unix”, może go rozwiązać.

Możesz to również zrobić :set ff=unixw Vimie.

Znalazłem w kontenerach Ubuntu lxc, że jeśli rc.local ma idealnie poprawny shebang np

#!/bin/sh

zawiedzie, ale jeśli usuniesz shebang, to zadziała.

Nie do końca rozumiem, dlaczego lub jakiej powłoki używa. Myślę, że bombarduje też pierwsze niezerowe. (W innych instalacjach Ubuntu prawidłowy shebang nie stanowi problemu)

Musisz upewnić się, że /etc/rc.localjest wykonywany podczas uruchamiania serwera za pomocą polecenia:

sudo systemctl enable rc-local.service