Soluzione 1:
Invece di farlo manualmente, come suggerito nelle altre risposte, potresti anche cambiare lo script init. Basta aggiungere una riga del genere all'intestazione:
# chkconfig: 35 90 10
Questo istruirà chkconfig per aggiungere il servizio ai runlevel 3 e 5, con una posizione iniziale di 90 e una posizione finale di 10.
Soluzione 2:
Puoi modificare l'ordine rinominando i collegamenti simbolici in /etc/rcX.d/ dove x sarà il tuo livello di esecuzione.
Vedrai una serie di file che iniziano con Sxx o Kxx. I collegamenti S vengono tracciati durante l'avvio mentre quelli K vengono analizzati per l'arresto. La xx qui rappresenta l'ordine.
Ma questo ordine è impostato per un motivo, quindi fai attenzione mentre li cambi, ad esempio. ntpd dovrebbe avviarsi solo dopo che il sottosistema di rete è stato inizializzato.
Soluzione 3:
Vuoi leggere qualcosa sui tuoi runlevel e sulle directory rc.d. All'interno delle directory rc.d puoi trovare i collegamenti S e K, come S20apache K10apache, che è fondamentalmente ciò che ordina l'avvio/spegnimento degli script.
Sono state apportate alcune modifiche a questa architettura, ma la maggior parte dei Linux la utilizza ancora.
Soluzione 4:
Se sei arrivato qui, è probabile che tu abbia due servizi in cui uno dipende dall'altro ma, poiché iniziano nell'ordine sbagliato, quello con la dipendenza non si avvia. I suggerimenti sulla modifica dei collegamenti simbolici sono informativi, in termini di illustrazione di come viene eseguita la sequenza di avvio, e funzionerebbero bene fino a quando qualcuno non eseguisse un "chkconfig on" sul tuo servizio, a quel punto i collegamenti simbolici verrebbero ricreati come erano originariamente. In realtà, vuoi affrontare il problema a livello di script di init, che in realtà è molto meno complicato da fare comunque. Sarà anche coerente tra i diversi runlevel. Probabilmente non avrai bisogno di aggiungere una riga "# chkconfig" come suggerito nella risposta 4 poiché probabilmente ci sarà già una riga simile.
Userò un esempio di un server che esegue Openldap (slapd) con un backend di database MySQL (mysqld). Configurare quella coppia, e perché potresti volerlo, è tutta un'altra storia.
All'avvio, Openldap non si avvia perché dipende da MySQL e la sequenza di avvio lo fa tentare di avviarsi prima di esso - slapd ha la posizione 27 e mysqld ha la posizione 64
I collegamenti simbolici pertinenti in /etc/rc3.d/ sono
S27slapd -> ../init.d/slapd
and
S64mysqld -> ../init.d/mysqld
Cerco i valori impostati nei due script init:
[root ~]# grep chkconfig /etc/rc.d/init.d/mysqld
# chkconfig: - 64 36
[root ~]# grep chkconfig /etc/rc.d/init.d/slapd
# chkconfig: - 27 73
Modifico la riga chkconfig in /etc/rc.d/init.d/slapd per avere una posizione iniziale più alta di quella in /etc/rc.d/init.d/mysqld (ho scelto 85)
[root ~]# grep chkconfig /etc/rc.d/init.d/slapd
# chkconfig: - 85 73
Eseguo "chkconfig slapd on" e ricontrollo i collegamenti simbolici
[root ~]# chkconfig slapd on
[root ~]# ls -l /etc/rc3.d/ | grep mysqld
lrwxrwxrwx 1 root root 16 Dec 10 13:45 S64mysqld -> ../init.d/mysqld
[root ~]# ls -l /etc/rc3.d/ | grep slapd
lrwxrwxrwx 1 root root 15 Apr 28 14:18 S85slapd -> ../init.d/slapd
Ora, quando questo server si avvia, mysqld si avvia prima di slapd e tutto va bene per il mondo.