web-dev-qa-db-fra.com

Pourquoi la commande dans /etc/rc.local n’est-elle pas exécutée au démarrage?

J'ai une seule commande dans mon script /etc/rc.local qui est supposée démarrer le démon de mise à jour pour Tiny Tiny RSS au démarrage, mais le script n'est pas exécuté au démarrage. Pourquoi?

L'ensemble du fichier /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 est exécutable:

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

/etc/init.d/rc.local existe et est exécutable:

# 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 est supposé être exécuté au démarrage pour ce niveau d'exécution:

# 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

Si j'appelle manuellement /etc/rc.local à partir de la ligne de commande, update_daemon se charge ...

# /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

... ce que je dois me rappeler de faire chaque fois que mon serveur redémarre jusqu'à ce que ce problème soit résolu.

similairequestionsdéjà existe, mais jusqu'à présent, je n'ai pas pu appliquer les informations qu'il contient à mon problème spécifique.

Pourquoi la commande dans rc.local n'est-elle pas exécutée au démarrage?

bootserverscriptsstartuptt-rss
37
x-x

Le script rc.local se ferme si une erreur survient lors de l'exécution de l'une de ses commandes (mentionnez l'indicateur -e dans #!/bin/sh -e).

Il est possible que certaines conditions préalables ne soient pas remplies lorsque vous essayez d'exécuter vos commandes lorsque l'exécution de rc.local a lieu. L'exécution de votre commande échoue donc.

J'ai rencontré la même chose en configurant manuellement le gouverneur cpu et en échouant dans rc.local. Voici ma solution de contournement personnalisée, qui utilise update-rc.d pour que vos commandes soient exécutées au démarrage:

  1. Créez un fichier myscript.sh dans le répertoire /etc/init.d avec un en-tête: #!/bin/sh
  2. Mettez vos commandes personnalisées comme contenu
  3. Rendez-le exécutable: Sudo chmod +x /etc/init.d/myscript.sh
  4. Créez des liens symboliques pour votre script pour différents niveaux d'exécution: Sudo update-rc.d myscript.sh defaults

Vous pouvez également vérifier les scripts /etc/network/if-up.d et voir si vous pouvez déclencher vos commandes au démarrage de la mise en réseau.

22
Drew

essayez Sudo sysv-rc-conf et vérifiez si rc.local est activé

rc.local         [ ]   [x]   [x]   [x]   [x]   [ ]   [ ]   [ ]
5
zuba

j'ai eu un problème similaire dans rc.local ne pas exécuter au démarrage

sshades m'a fourni la réponse suivante:

Ubuntu utilise maintenant systemd et rc.local est maintenant considéré comme un service qui est désactivé par défaut. Vous pouvez activer "rc.local" en entrant la commande suivante et en redémarrant:

Sudo systemctl enable rc-local.service

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

bien que je n'aie pas testé sa solution, je pense que cela semble logique et que cela fonctionnera. Toutefois :

J'ai également trouvé une solution qui ajoute un script à ./.config/autostart-scripts/ fera l'affaire

5
Diet Bos

Assurez-vous que le script rc.local est exécutable:

Sudo chmod +x /etc/rc.local

Ensuite, activez-le:

Sudo systemctl enable rc-local.service

Redémarrez le système ou démarrez le script manuellement en lançant:

Sudo systemctl start  rc-local.service

Le statut du service peut être affiché en exécutant:

$ 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
4
leobocao

Nous avons eu ce problème sur certains serveurs hébergés chargeant des règles FW.

Sur ces boîtes, ils redémarrent TRÈS rapidement et nous avons trouvé qu’il suffisait de mettre un "sommeil 1" dans rc.local avant que les instructions de chargement ne semblent résoudre le problème. Je suppose que cela a laissé un peu de temps pour que les interfaces se règlent avant de charger les règles FW.

3
Simon Hart

Une fois, j'ai édité rc.local avec le Bloc-notes sous Windows et le problème a commencé à se poser.

Dans ce cas, l'utilisation d'un éditeur de texte prenant en charge la conversion EOL, telle que Notepad ++, pour convertir le style EOL en 'Unix', peut résoudre le problème.

Vous pouvez également le faire avec :set ff=unix dans Vim.

1
SyaSyaNown

Vous devrez vous assurer que /etc/rc.local est exécuté lors du démarrage du serveur avec la commande:

Sudo systemctl enable rc-local.service

0
William

J'ai trouvé dans les conteneurs Ubuntu lxc que si rc.local a un Shebang parfaitement correct, par exemple.

#!/bin/sh

cela échoue, mais si vous supprimez le Shebang, cela fonctionne.

Pas au courant de pourquoi ou de ce que Shell utilise, je pense qu'il bombarde également le premier non nul. (Dans d'autres installations d'Ubuntu, Shebang n'est pas un problème)

0
teknopaul