Exécuter le script avec rc.local: le script fonctionne, mais pas au démarrage
J'ai un script node.js qui doit démarrer au démarrage et exécuté sous l'utilisateur www-data. Pendant le développement, j'ai toujours commencé le script avec:
su www-data -c 'node /var/www/php-jobs/manager.js
J'ai vu exactement ce qui s'est passé, le manager.js fonctionne maintenant très bien. Recherche SO J'ai trouvé que je devais l'insérer dans mon /etc/rc.local. De plus, j'ai appris à pointer la sortie dans un fichier journal et à ajouter le 2>&1 à "rediriger stderr vers stdout" et il devrait s'agir d'un démon afin que le dernier caractère soit un &.
Enfin, mon /etc/rc.local ressemble à ceci:
#!/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.
su www-data -c 'node /var/www/php-jobs/manager.js >> /var/log/php-jobs.log 2>&1 &'
exit 0
Si je lance ça moi-même (Sudo /etc/rc.local): oui, ça marche! Cependant, si j'effectue un redémarrage, aucun processus node n'est en cours d'exécution, le /var/log/php-jobs.log n'existe pas et, par conséquent, manager.js ne fonctionne pas. Qu'est-ce qui se passe?
Je me suis retrouvé avec upstart , qui fonctionne bien.
Dans cet exemple de script rc.local, j'utilise la redirection io dès la première ligne d'exécution vers mon propre fichier journal:
#!/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.
exec 2> /tmp/rc.local.log # send stderr from rc.local to a log file
exec 1>&2 # send stdout to the same log file
set -x # tell sh to display commands before execution
/opt/stuff/somefancy.error.script.sh
exit 0
Sur certains linux (Centos et RH, par exemple), /etc/rc.local est au départ juste un lien symbolique vers /etc/rc.d/rc.local. Sur ces systèmes, si le lien symbolique est rompu et que /etc/rc.local est un fichier séparé, les modifications apportées à /etc/rc.local ne seront pas visibles au démarrage. Le processus de démarrage exécutera la version dans /etc/rc.d. (Ils fonctionneront si l'un exécute /etc/rc.local manuellement, mais ne sera pas exécuté au démarrage.)
Cela ressemble au système de dimadima, ce sont des fichiers séparés, mais /etc/rc.d/rc.local appelle /etc/rc.local
Le lien symbolique de /etc/rc.local vers le 'réel' dans /etc/rc.d peut être perdu si on déplace rc.local dans un répertoire de sauvegarde et le recopie ou le crée à partir de rien, ne réalisant pas que celui d'origine dans /etc n'était qu'un lien symbolique.
Dans Ubuntu, j'ai remarqué qu'il y a 2 fichiers. Le vrai est /etc/init.d/rc.local; il semble que l'autre /etc/rc.local est faux?
Une fois que j'ai modifié le correct (/etc/init.d/rc.local), il s'est exécuté comme prévu.
Vous avez également pu le faire fonctionner en spécifiant le chemin complet du noeud. En outre, lorsque vous souhaitez exécuter une commande Shell en tant que démon, fermez stdin en ajoutant 1 <& - avant le &.
J'ai eu le même problème (sur CentOS 7) et je l'ai corrigé en donnant les permissions d'exécution à/etc/local:
chmod +x /etc/rc.local
si vous utilisez Linux sur le cloud, vous n’avez généralement pas la possibilité de toucher le vrai matériel avec vos mains. de sorte que vous ne voyez pas l'interface de configuration lorsque vous démarrez pour la première fois, et bien sûr, vous ne pouvez pas la configurer. Par conséquent, le service firstboot sera toujours sur le chemin de rc.local. La solution consiste à désactiver firstboot en procédant comme suit:
Sudo chkconfig firstboot off
si vous ne savez pas pourquoi votre rc.local ne s'exécute pas, vous pouvez toujours vérifier le fichier /etc/rc.d/rc car ce fichier sera toujours exécuté et appellera d'autres sous-systèmes (par exemple, rc.local).
J'utilise CentOS 7.
$ cd /etc/profile.d
$ vim yourstuffs.sh
Tapez ce qui suit dans le script yourstuffs.sh.
tapez ce que vous voulez ici pour exécuter
export LD_LIBRARY_PATH=/usr/local/cuda-7.0/lib64:$LD_LIBRARY_PATH
Enregistrez et redémarrez le système d'exploitation.
Mon script a fonctionné en éditant /etc/rc.local puis en émettant les 3 commandes suivantes.
Sudo mv /filename /etc/init.d/
Sudo chmod +x /etc/init.d/filename
Sudo update-rc.d filename defaults
Maintenant, le script fonctionne au démarrage.
J'ai utilisé rc.local dans le passé. Mon expérience m'a toutefois appris que le moyen le plus fiable d'exécuter votre script au démarrage du système est d'utiliser @reboot command dans crontab. Par exemple:
@reboot path_to_the_start_up_script.sh
Je crois comprendre que si vous placez votre script dans un certain niveau d’exécution, vous devez utiliser ln -s pour le lier au niveau souhaité.
Ceci est probablement dû à une variable d'environnement PATH manquante ou incomplète.
Si vous fournissez des chemins absolus complets à vos exécutables (su et noeud), cela fonctionnera.
commencez par rendre le script exécutable à l'aide de Sudo chmod 755 /path/of/the/file.shajoutez maintenant le script dans le fichier rc.local sh /path/of/the/file.sh avant de quitter 0 dans le fichier rc.local, Pour exécuter l'exécutable avec Sudo chmod 755 /etc/rc.localnext afin d'initialiser l'utilisation de rc.local Sudo /etc/init.d/rc.local start cela lancera rc.local maintenant redémarrer le système . Fait ..