Tengo un script perfectamente bueno para usar en /etc/init.d. De hecho, tengo muchos de ellos, todos creados con Tanuki Java Service Wrapper.
Me parece que podría haber una plantilla simple para envolver un script de shell como un script inicial, pero un poco de google no es revelador.
¿Me estoy perdiendo de algo?
Respuestas:
No recuerdo haber visto una plantilla para esto. Sin embargo, es un poco irónico que, técnicamente, es un arranque que está comenzando su script init.d en primer lugar gracias al trabajo de compatibilidad con versiones anteriores rc y rcS.
Consideraría reescribir lo que tenga como trabajo inicial, sin embargo, sé que algunos scripts son difíciles de convertir, así que esto es lo que hice durante un tiempo en algunos de mis scripts:
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
Ahora, dependiendo de la naturaleza del servicio, ya sea que persista o se bifurque, es posible que deba agregar expect forko taskal archivo de trabajo.
Solo para completar el pensamiento, por lo general, esto es todo lo que hay para un archivo de trabajo inicial completo de todos modos. Se realiza todo el trabajo previo al inicio, se realiza toda la limpieza, lo único que queda es el servicio en sí, que generalmente se agrega con:
exec service_cmd
Entonces, un punto de los trabajos iniciales es ser simple de escribir.
Hay mucha magia de script de shell en los guiones init.d que se repite una y otra vez. Declaraciones de casos, seguimiento de archivos pid, líneas de comentarios lsb. No está muy claro cómo escribir un BUEN script init.d sin haber leído uno.
Si ya ha tenido problemas para escribir todo eso, entonces no necesita un trabajo inicial a menos que, como mencioné en otro comentario, dependa de otro trabajo / evento inicial.
Pero realmente, el advenedizo hace las cosas realmente simples. No debería necesitar un inicio previo a menos que necesite configurar cosas como tmpdirs, ulimits o argumentos de tiempo de ejecución. No debería necesitar una parada posterior a menos que desee asegurarse de ordenar después de un servicio (el servicio realmente debería estar limpiando después de sí mismo en la salida normal).
Muchas veces un script init.d gigante con muchas opciones se reduce a un trabajo inicial de 10 a 15 líneas. Los scripts de init.d más complejos pueden tener la mayor parte de su lógica volcada en pre-start. La clave es que es solo un pequeño fragmento de código para configurar el entorno para el proceso, y no una lógica en el manejo de inicio / detención / reaparición / etc.
La parte más difícil, y la que la gente se equivoca con más frecuencia, es saber cuándo comenzar / detener su trabajo. start on runlevel [2345]Parece lógico, pero ignora el hecho de que la red está llegando en paralelo en ese punto, al igual que los montajes del sistema de archivos local. La clave es tratar de averiguar exactamente las cosas mínimas que necesita (otros servicios, sistemas de archivos, red, etc.) para comenzar a funcionar, y comenzar cuando estén listos. La mayoría de los servicios de red tradicionales deberían hacerlo start on (local-filesystems and net-device-up IFACE!=lo).
Pensé que Upstart mantiene la compatibilidad con versiones anteriores con scripts de inicio de estilo SysV /etc/init.d. Debería poder usar sus scripts de inicio sin cambios.
/etc/init.d/myservice startpara /etc/rc.local, en el orden correcto. Esto asegurará que sus servicios se inicien en último lugar, después de todos los demás servicios, incluidos los iniciados por las secuencias de comandos de inicio Upstart.