dans cet exemple de rc.script local j'utilise la redirection io à la toute première ligne d'exécution vers mon propre fichier log:

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

On some linux (Centos & RH, e.g.),/etc/rc.local n'est au départ qu'un lien symbolique vers /etc/rc.d/rc.local. Sur ces systèmes, si le lien symbolique est cassé, et /etc/rc.local est un fichier séparé, puis change en /etc/rc.local n'obtiendrez pas vu lors de l'initialisation -- le processus de démarrage d'exécuter la version /etc/rc.d. (Ils fonctionneront si on court!--0--> manuellement, mais ne sera pas exécuté au démarrage.)

on dirait que sur le système de dimadima, ce sont des fichiers séparés, mais /etc/rc.d/rc.local appelle /etc/rc.local

le lien symbolique à partir d' /etc/rc.local la 'vraie' un /etc/rc.d peut se perdre si l'on passe rc.local à un répertoire de sauvegarde et le copie en arrière ou le crée à partir de zéro, ne réalisant pas l'original en /etc n'était qu'un lien symbolique.

dans Ubuntu j'ai remarqué qu'il y a 2 fichiers. Le réel est /etc/init.d/rc.local; il semble que les autres /etc/rc.local est faux?

une fois que j'ai modifié le bon (/etc/init.d/rc.local) il s'est exécuté comme prévu.

vous auriez pu aussi le faire fonctionner en spécifiant le chemin complet vers le noeud. De plus, lorsque vous voulez exécuter une commande shell en tant que démon, vous devez fermer stdin en ajoutant 1<&- avant le &.

si vous utilisez linux sur cloud, vous n'avez généralement pas la possibilité de toucher le matériel réel en utilisant vos mains. donc vous ne voyez pas l'interface de configuration lors du démarrage pour la première fois, et bien sûr ne pouvez pas la configurer. En conséquence, le firstboot service sera toujours dans le bon chemin rc.local. La solution est de désactiver firstboot en faisant:

sudo chkconfig firstboot off

si vous n'êtes pas sûr pourquoi votre rc.local ne fonctionne pas, vous pouvez toujours vérifier à partir de /etc/rc.d/rc fichier car ce fichier toujours exécuter et appeler d'autres sous-systèmes (par exemple rc.local.)

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

j'ai eu mon script fonctionne en modifiant /etc/rc.local puis l'émission des 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'utilise CentOS 7.

$ cd  /etc/profile.d

$ vim yourstuffs.sh

Tapez ce qui suit dans le yourstuffs.sh script.

Tapez tout ce que vous voulez ici pour exécuter

export LD_LIBRARY_PATH=/usr/local/cuda-7.0/lib64:$LD_LIBRARY_PATH

enregistrer et redémarrer le système D'exploitation.

Ceci est très probablement causé par une variable d'environnement de chemin manquante ou incomplète.

si vous fournissez des chemins absolus complets vers vos exécutables (su et node), cela fonctionnera.

je comprends que si vous placez votre script dans un certain niveau D'exécution, vous devriez utiliser ln-s pour lier le script au niveau dans lequel vous voulez qu'il fonctionne.

j'ai utilisé rc.local dans le passé. Mais j'ai appris de mon expérience que le moyen le plus fiable pour exécuter votre script au démarrage du système est d'utiliser @reboot commande crontab. Par exemple:

@reboot path_to_the_start_up_script.sh

tout d'abord, rendre le script exécutable en utilisant sudo chmod 755 /path/of/the/file.sh Maintenant, ajoutez le script dans la rc.local sh /path/of/the/file.sh avant la sortie 0 dans la rc.local, ensuite, faites le rc.local à exécutable avec sudo chmod 755 /etc/rc.local suivante pour initialiser le rc.l'utilisation locale sudo /etc/init.d/rc.local start cela va lancer la rc.local maintenant, redémarrez le système. Faire..

1 ne recommande pas l'utilisation de root pour exécuter les applications telles que node app.

eh Bien, vous pouvez le faire, mais peut attraper plus d'exceptions.

2 La rc.local fonctionne normalement en tant qu'utilisateur root.

donc si votre script s'exécute comme un autre utilisateur tel que www U doit s'assurer que le chemin et l'autre environnement sont ok.

3-je trouver un moyen facile d'exécuter un service en tant qu'utilisateur:

sudo -u www -i /le/chemin/de/votre/script

s'il vous plaît préférez le sudo manuel~ -je [commande] L'option-i (simulate initial login) exécute le shell spécifié par l'entrée de la base de données de mots de passe de l'utilisateur cible comme loginshell...

rc.local ne fonctionne qu'au démarrage. Si vous redémarrez et que vous voulez que le script s'exécute, il doit aller dans le rc.0 fichier commençant par le préfixe K99.