Ho uno script perfettamente valido per l'uso in /etc/init.d. In effetti, ne ho molti, tutti creati con il Tanuki Java Service Wrapper.
Mi sembra che potrebbe esserci un modello semplice per racchiudere uno script di shell come uno script di avvio, ma un po 'di googling non sta rivelando uno.
Mi sto perdendo qualcosa?
Risposte:
Non ricordo di aver visto un modello per questo. È un po 'ironico, tuttavia, dal punto di vista tecnico, è il suo avvio che sta iniziando il tuo script init.d in primo luogo grazie al processo di compatibilità con le versioni precedenti rc e rcS.
Vorrei prendere in considerazione la riscrittura di qualsiasi cosa tu abbia come lavoro iniziale, tuttavia, so che alcuni script sono difficili da convertire, quindi ecco cosa ho fatto per un po 'su alcuni dei miei script:
description "xyz"
author "xyz"
start on runlevel 5
stop on runlevel [!5]
pre-start script
# do my work here to start the service
end script
post-stop script
# do work here to stop the service
end script
Ora, a seconda della natura del servizio, indipendentemente dal fatto che persista o esegua il fork, potrebbe essere necessario aggiungere expect forko taskil file di lavoro.
Solo per completare il pensiero, di solito, questo è tutto ciò che c'è da fare comunque per un file di lavoro completo. Tutto il lavoro pre-avvio viene eseguito, tutta la pulizia viene eseguita, l'unica cosa rimasta è il servizio stesso che di solito viene aggiunto con:
exec service_cmd
Quindi un punto dei lavori iniziali è quello di essere semplici da scrivere.
C'è molta magia nella shell script negli script init.d che viene ripetuta più volte. Dichiarazioni di caso, tracciamento pidfile, righe di commento lsb. Non è molto chiaro come scrivere un BUON script init.d senza averne letto uno.
Se hai già avuto il problema di scrivere tutto ciò, allora non hai bisogno di un lavoro iniziale a meno che, come ho già detto in un altro commento, dipenda da un altro lavoro / evento iniziale.
Ma davvero, upstart rende le cose davvero semplici. Non dovresti aver bisogno di un pre-avvio a meno che non sia necessario impostare cose come tmpdirs, ulimits o argomenti di runtime. Non dovresti aver bisogno di un post-stop se non vuoi assicurarti di riordinare dopo un servizio (il servizio dovrebbe davvero ripulire dopo se stesso all'uscita normale).
Spesso uno script init.d gigante con molte opzioni si riduce a un lavoro iniziale di 10-15 righe. Gli script init.d più complessi possono avere la maggior parte della loro logica scaricata in pre-avvio. La chiave è che è solo un piccolo frammento di codice per configurare l'ambiente per il processo, e non la logica sulla gestione di start / stop / respawn / etc.
La parte più difficile, e quella in cui le persone si sbagliano più spesso, è sapere quando iniziare / interrompere il loro lavoro. start on runlevel [2345]sembra logico, ma ignora il fatto che la rete si sta sviluppando in parallelo in quel punto, così come i montaggi di filesystem locali. La chiave è cercare di capire esattamente le cose minime necessarie (altri servizi, filesystem, rete, ecc.) Per iniziare a funzionare e iniziare al termine. La maggior parte dei servizi di rete tradizionali dovrebbe fare start on (local-filesystems and net-device-up IFACE!=lo).
Ho pensato che Upstart mantenga la retrocompatibilità con gli script di init in stile SysV /etc/init.d. Dovresti essere in grado di usare invariati i tuoi script init.
/etc/init.d/myservice startper /etc/rc.local, nell'ordine corretto. Ciò garantirà che i servizi vengano avviati per ultimi, dopo tutti gli altri servizi, compresi quelli avviati dagli script di avvio Upstart.