codice bash in rc.local non eseguito dopo l'avvio

Qualcuno sa perché un sistema non eseguirà il codice di script all'interno di rc.local all'avvio? Ho uno script bash post-configurazione che voglio eseguire dopo l'installazione iniziale di VMware ESX (Red Hat), e per qualche motivo non sembra eseguirlo. Ho la configurazione per registrare il suo inizio dell'esecuzione e anche i suoi progressi in modo da poter vedere fino a che punto arriva nel caso fallisca ad un certo punto, ma anche quando guardo quel registro, sto scoprendo che non ha nemmeno avviato il esecuzione del codice di script. Ho già controllato per vedere che lo script ha i permessi di esecuzione (755), cos'altro dovrei guardare?

Ecco le prime righe del mio codice:

#!/bin/sh
echo >> /tmp/configLog ""
echo >> /tmp/configLog "Entering maintenance mode"

Quindi, esiste / tmp / configLog? In tal caso, la tua sceneggiatura si sta attivando e sta morendo da qualche parte.

Inizia con le basi:

1. Inserisci un semplice one-liner in /etc/rc.local, in questo modo.

   touch / tmp / ha funzionato

   Ha funzionato? Dopo il riavvio, esiste / tmp / itworked? In tal caso, viene eseguito rc.local.
2. Un altro gotcha comune è che se il tuo script è un demone o deve gestire il fork in background, oppure deve essere in background in rc.local. Se il tuo script è / bin / myscript, allora rc.local dovrebbe avere:

   / bin / myscript &

   dentro. Ci vuole molto tempo per correre? Potrebbe esserci un timeout da qualche parte negli script init per impedire agli utenti di arrestare il processo di avvio - se lo si fa in background il processo lo aggirerà se esiste.
3. Se il 'tocco' funziona e stai facendo lo sfondo, deve essere nella tua sceneggiatura da qualche parte. Cosa fa quando corri

   / bin / sh /etc/rc.local

   dalla riga di comando?
4. Come ha detto Jason, controlla dmesg, così come / var / log / messaggi per eventuali indizi.
5. Quando lo script viene eseguito da rc.local, non avrà l'intero set di variabili d'ambiente che l'utente root ha quando ha effettuato l'accesso - ad esempio $ PATH potrebbe essere diverso. Non fare affidamento su $ PATH. Puoi anche testare il tuo script programmando un lavoro "at" che si avvicina alla simulazione dell'ambiente.

Non è qualcosa di semplice come un refuso, vero? Questo dovrebbe:

#!/bin/hash

Essere davvero:

#!/bin/bash

?

(Proprio come ha detto CK nel commento, ora che guardo)

Sei sicuro che il tuo sistema supporti rc.local? Se non è documentato, dovrai seguire tutti gli script init. Si inizia da / etc / inittab. (Potresti scoprire che da lì vai a /etc/rc.d/rc)

Su alcuni sistemi, /etc/rc.d/rc.local è supportato tramite un link simbolico /etc/rc.d/rcX.d/S99local. (dove X è il runlevel appropriato).

Se stai usando RedHat, non c'è alcun motivo reale per non creare il tuo script init, aggiungerlo a /etc/rc.d/init.d, chkconfig --add lo script e chkconfig sullo script. Ciò renderà i collegamenti simbolici corretti nelle directory /etc/rc.d/rcX.d e renderà gli script init facili da distribuire o disabilitare.

Fare uso del obsoleto rc.local va bene per un hack rapido se il tuo sistema lo supporta, ma non è davvero appropriato per qualcosa di importante o permanente.

Non sono sicuro che l'elaborazione degli script init su Linux sia sequenziale o parallela, ma i sistemi Solaris lanciano gli script in sequenza. Se uno script di init precedente non è ancora terminato (lo vedo a volte a causa della dipendenza sendmail / DNS), quelli successivi non vengono avviati così rapidamente come si suppone.

Usa ps per vedere se uno script init precedente è ancora in esecuzione.

Forse c'è un errore di sintassi nello script rc.local. Se si tenta di eseguirlo manualmente dalla riga di comando dopo l'avvio del sistema, viene eseguito correttamente?

Hai controllato le autorizzazioni sulla directory che contiene il file rc.local?

Il tuo codice non dovrebbe apparire più così? 3 modifiche qui:

#!/bin/bash
echo "" >> /tmp/configLog
echo "Entering maintenance mode" >> /tmp/configLog

rc.local era il modo BSD di eseguire script di avvio. Sebbene molte versioni di Linux supportino il fatto di avere un file chiamato "rc.local" che viene eseguito all'avvio, poiché ricordo che questi richiedono un mucchio di collegamenti simbolici e altra colla per funzionare, poiché Linux ha seguito il modo Solaris di gestire gli script di avvio.

SELinux.

Prova getenforce per vedere se selinux è acceso. Restituirà 1 o applicherà se è acceso. Quindi se è controllare dmesg per vedere se c'è un errore relativo a selinux che potrebbe avere a che fare con il tuo script.

Se quella prima riga dice davvero #! / Bin / hash, otterrai un errore simile al seguente:

-bash: ./test.sh: /bin/hash: bad interpreter: No such file or directory

quando corre.

È inoltre possibile verificare che lo script disponga delle autorizzazioni di esecuzione.