Esegui script con rc.local: lo script funziona, ma non all'avvio

Question

Ho uno script node.js che deve essere avviato all'avvio e eseguito sotto l'utente www-data. Durante lo sviluppo ho sempre iniziato la sceneggiatura con:

su www-data -c 'node /var/www/php-jobs/manager.js 

Ho visto esattamente cosa è successo, il manager.js funziona ora alla grande. Cercando così ho scoperto che dovevo collocarlo nel mio /etc/rc.local. Inoltre, ho imparato a puntare l'output su un file di log e ad aggiungere lo 2>&1 a "redirect stderr to stdout" e dovrebbe essere un demone, quindi l'ultimo carattere è un &.

Infine, la mia /etc/rc.local assomiglia a questo:

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

Se corro io stesso (sudo /etc/rc.local): sì, funziona! Tuttavia, se eseguo un riavvio no processo node è in esecuzione, il /var/log/php-jobs.log non esiste e, quindi, il manager.js non funziona. Che cosa sta succedendo?

Answer 1

Ho finito con upstart, che funziona bene.

Answer 2

Si potrebbe anche averlo fatto specificando il percorso completo al nodo. Inoltre, quando si desidera eseguire un comando shell come daemon, è necessario chiudere lo stdin aggiungendo 1 < & - prima dello &.

Answer 3

In Ubuntu ho notato che ci sono 2 file. Quello vero è /etc/init.d/rc.local; sembra che l'altro /etc/rc.local sia fasullo?

Una volta modificato quello corretto (/etc/init.d/rc.local) è stato eseguito esattamente come previsto.

Answer 4

In questo esempio di uno script rc.local che uso io reindirizzamento alla prima riga di esecuzione al mio file di registro:

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

Answer 5

ho ottenuto il mio script per lavorare modificando /etc/rc.local poi rilascia la seguente 3 comandi.

sudo mv /filename /etc/init.d/ 
sudo chmod +x /etc/init.d/filename 
sudo update-rc.d filename defaults 

Ora lo script funziona all'avvio.

Answer 6

Questo è probabilmente causato da una variabile di ambiente PATH mancante o incompleta.

Se fornisci percorsi assoluti completi ai tuoi eseguibili (su e nodo) funzionerà.

Answer 7

rc.local viene eseguito solo all'avvio. Se si riavvia e si desidera eseguire lo script, è necessario accedere al file rc.0 che inizia con il prefisso K99.

Answer 8

Su alcuni linux (Centos & RH, ad esempio), /etc/rc.local è inizialmente solo un collegamento simbolico a /etc/rc.d/rc.local. Su quei sistemi, se il collegamento simbolico è interrotto e /etc/rc.local è un file separato, le modifiche a /etc/rc.local non verranno visualizzate all'avvio - il processo di avvio eseguirà la versione in /etc/rc.d. (Funzioneranno se uno esegue /etc/rc.local manualmente, ma non verrà eseguito all'avvio.)

Suona come il sistema di dimadima, sono file separati, ma /etc/rc.d/rc.local chiama /etc/rc.local

Il collegamento simbolico dal /etc/rc.local alla 'vera' uno in /etc/rc.d può perdere se ci si muove rc.local ad una directory di backup e copie torna indietro o lo crea da zero, non rendendosi conto di quello originale in /etc era solo un collegamento simbolico.

Answer 9

se si utilizza Linux su cloud, di solito non si ha la possibilità di toccare il vero hardware con le mani. quindi non si vede l'interfaccia di configurazione quando si avvia per la prima volta e, naturalmente, non è possibile configurarlo. Di conseguenza, il servizio firstboot sarà sempre sulla strada per rc.local. La soluzione è quella di disabilitare firstboot facendo:

sudo chkconfig firstboot off 

se non si è sicuri perché il vostro rc.local non viene eseguito, si può sempre controllare da /etc/rc.d/rc file perché questo file sarà sempre correre e chiamare altri sottosistemi (ad esempio rc.local).

Answer 10

1 Non è consigliabile utilizzare root per eseguire app come l'app nodo.

Beh, puoi farlo, ma potresti avere più eccezioni.

2 Il file rc.local normalmente viene eseguito come utente root.

Quindi, se lo script deve essere eseguito come un altro utente come www U, assicurarsi che il PERCORSO e l'altro ambiente siano corretti.

3 trovo un modo semplice per eseguire un servizio come utente:

sudo -u www -i/la/percorso/del/la vostra/script

Si prega di preferire il manuale di sudo ~ - i [comando] L'opzione -i (simula l'accesso iniziale) esegue la shell specificata dalla voce del database delle password dell'utente di destinazione come un loginshell ...

Answer 11

Ho avuto lo stesso problema (su CentOS 7) e ho risolto dando autorizzazioni di esecuzione a/etc/local:

chmod +x /etc/rc.local 

Answer 12

Sto usando CentOS 7.

$ cd /etc/profile.d 

$ vim yourstuffs.sh 

Digitare il seguente nello script yourstuffs.sh.

tipo quello che vuoi qui per eseguire

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

Salva e riavviare il sistema operativo.

Answer 13

E 'la mia comprensione che se si inserisce lo script in un certo livello di esecuzione, si dovrebbe usare ln -s per collegare lo script per il livello desiderato di lavorare in.

Answer 14

ho usato rc.local nel passato. Ma ho appreso dalla mia esperienza che il modo più affidabile per eseguire lo script all'avvio del sistema consiste nell'utilizzare il comando @reboot in crontab.Ad esempio:

@reboot path_to_the_start_up_script.sh