Pregunto en ambos contextos: técnica y estilísticamente.¿Mi archivo pidfile debe estar ubicado en/var/run?
¿Puede mi aplicación/daemon mantener un archivo pid en /opt/my_app/run/?
¿Es muy malo hacerlo?
Mi necesidad es esta: mi daemon se ejecuta bajo un usuario específico, y el implementador debe crear un nuevo directorio en /var/run, chown y chgrp para ejecutar mi daemon. Parece más fácil simplemente mantener el archivo pidfile local (al daemon).
No pondría un archivo pid en un directorio de instalación de la aplicación como /opt/my_app/whatever. Este directorio podría montarse como de solo lectura, podría compartirse entre máquinas, podría ser visto por un daemon que trate cualquier cambio como posible intento de robo ...
La ubicación normal para los archivos pidf es /var/run. La mayoría de los equipos limpiarán este directorio en el arranque; en Ubuntu esto se logra mediante /var/run un sistema de archivos en memoria (tmpfs).
Si inicia el daemon desde una secuencia de comandos que se ejecuta como raíz, haga que cree un subdirectorio /var/run/gmooredaemon y que lo asigne al usuario que ejecuta daemon antes de su iniciar el daemon.
En muchos sistemas Linux modernos, si inicia el daemon desde un script o iniciador que no se ejecuta como root, puede poner el archivo pid en /run/user/$UID, que es un equivalente por usuario del /var/run tradicional.
De lo contrario, elija una ubicación en /tmp o /var/tmp, pero esto presenta una complejidad adicional porque el nombre del archivo del pid no se puede determinar de manera única si está en un directorio de escritura mundial.
En cualquier caso, facilite (la opción de línea de comandos, más tal vez una opción de tiempo de compilación) para que el distribuidor o el administrador cambien la ubicación de los archivos pidfile.
La ubicación del archivo pid debe ser configurable./var/run es estándar para los archivos pid, lo mismo que/var/log es estándar para los registros. Pero su daemon debería permitirle sobrescribir esta configuración en algún archivo de configuración.
/opt se utiliza para instalar aplicaciones 'autónomas', por lo que no hay nada de malo aquí. Usando /opt/my_app/etc/ para archivos de configuración, /opt/my_app/log/ para registros, etc., es una práctica común para este tipo de aplicación.
De esta forma puede distribuir sus aplicaciones como un archivo TGZ en lugar de mantener un paquete para cada administrador de paquetes (al menos DEB desde que marcó ubuntu). Lo recomendaría para aplicaciones internas o situaciones en las que tenga un gran control sobre el medio ambiente. El razonamiento es que no tiene sentido si la caja fuerte cuesta más de lo que está poniendo adentro (el trabajo requerido para empacar la aplicación no debe eclipsar el esfuerzo requerido para escribir la aplicación).
Otra convención, si no está ejecutando el script como root, es poner el archivo pid en ~/.my_app/my_app.pid. Es más simple de esta manera sin dejar de ser seguro ya que el directorio de inicio no es escribible en todo el mundo.
Esto sería bueno si cada usuario puede ejecutar una instancia de su aplicación sin conflicto. De lo contrario, me quedaría con/var/run – dlite922
/run ahora es solo de escritura por el propietario (raíz). ¿Cómo escribirían las aplicaciones un archivo pidf allí? – TSG
@TSG Las distribuciones modernas generalmente crean un directorio por usuario en '/ run/user'. No recuerdo que '/ run' haya sido editable por todos.Pero los archivos pidfiles en '/ run' son comunes, sin embargo, son la norma para los servicios del sistema. El archivo pidfile está escrito por un supervisor que se ejecuta como root, o por un script de inicio que se ejecuta como root antes de iniciar el daemon real con privilegios posiblemente reducidos. – Gilles