El mejor lugar para colocar los archivos de la unidad del sistema : /etc/systemd/system
solo asegúrese de agregar un objetivo en la sección [Instalar], lea "¿Cómo lo sabe?" para detalles. ACTUALIZACIÓN : /usr/local/lib/systemd/systemes otra opción, lea "Área gris" para más detalles ".
El mejor lugar para colocar archivos de unidad de usuario : /etc/systemd/user o $HOME/.config/systemd/user
depende de los permisos y la situación.
La verdad es que las unidades systemd (o como las llama la frase introductoria, "configuraciones de unidades") pueden ir a cualquier parte, siempre que esté dispuesto a hacer enlaces simbólicos manuales y esté al tanto de las advertencias. Hace que sea más fácil colocar la unidad donde systemctl daemon-reloadpueda encontrarla por algunas buenas razones:
- El uso de una ubicación estándar significa que los generadores systemd los encontrarán y facilitarán su activación en el arranque
systemctl enable. Esto se debe a que su unidad se agregará automáticamente a un árbol de dependencia de la unidad (un caché de la unidad).
- No necesita pensar en los permisos, porque solo los usuarios privilegiados correctos pueden escribir en las áreas designadas.
Como lo sabe
¿Y cómo systemctl enablesabe exactamente dónde crear el enlace simbólico? Lo codifica dentro de la unidad en la [install]sección. Por lo general, hay una línea como
[Install]
WantedBy = multi-user.target
que corresponde a un lugar predefinido en el sistema de archivos. De esta manera, systemctlsabe que esta unidad depende de un grupo de archivos de unidad llamado multi-user.target("destino" es el término utilizado para designar grupos de dependencia de unidad. Puede enumerar todos los grupos con systemctl list-units --type target). El grupo de archivos de unidad que se cargará con un destino se coloca en un targetname.target.wantsdirectorio. Esto es solo un directorio lleno de enlaces simbólicos (o lo real). Si su [Install]sección dice que es WantedByel multi-user.target, pero si no existe un enlace simbólico en el multi-user.target.wantsdirectorio, entonces no se cargará. Cuando los generadores de unidades systemd agregan su archivo de unidad a la caché del árbol de dependencias en el arranque (puede activar manualmente los generadores con systemctl daemon-reload), automáticamente sabe dónde colocar el enlace simbólico, en este caso en el directorio/etc/systemd/system/multi-user.target.wants/ ¿Deberías habilitarlo?
Puntos clave en el manual:
Se pueden cargar unidades adicionales en systemd ("vinculadas") desde directorios que no están en la ruta de carga de la unidad. Vea el comando de enlace para systemctl (1).
En systemctl, busque Comandos de archivo de unidad
Ruta de carga del archivo de unidad
Los archivos de la unidad se cargan desde un conjunto de rutas determinadas durante la compilación, descritas en las dos tablas a continuación. Los archivos de unidad que se encuentran en los directorios enumerados anteriormente anulan los archivos con el mismo nombre en los directorios más bajos de la lista.
Cuando $SYSTEMD_UNIT_PATHse establece la variable , el contenido de esta variable anula la ruta de carga de la unidad. Si $SYSTEMD_UNIT_PATHtermina con un componente vacío (":"), la ruta de carga unitaria habitual se agregará al contenido de la variable.
La tabla 1 y la tabla 2 de man systemd.unitson buenas.
Cargue rutas cuando se ejecuta en modo sistema ( --system).
/etc/systemd/system Configuración local/run/systemd/system Unidades de tiempo de ejecución/usr/lib/systemd/system Unidades de paquetes instalados
Cargar ruta cuando se ejecuta en modo de usuario ( --user)
Hay una diferencia entre las unidades por usuario y todas las unidades de usuarios globales .
Dependiente del usuario
$XDG_CONFIG_HOME/systemd/user Configuración del usuario (solo se usa cuando $XDG_CONFIG_HOMEestá configurado)$HOME/.config/systemd/user Configuración del usuario (solo se usa cuando $XDG_CONFIG_HOMEno está configurado)$XDG_RUNTIME_DIR/systemd/user Unidades de tiempo de ejecución (solo se usa cuando $XDG_RUNTIME_DIRestá configurado)
$XDG_DATA_HOME/systemd/user Unidades de paquetes que se han instalado en el directorio de inicio (solo se usa cuando $XDG_DATA_HOMEestá configurado)
$HOME/.local/share/systemd/user Unidades de paquetes que se han instalado en el directorio de inicio (solo se usa cuando $XDG_DATA_HOMEno está configurado)
--global (todos los usuarios)
Unidades que se aplican a todos los usuarios, lo que significa propiedad de cada usuario también. Por lo tanto, cada usuario puede detener estos servicios incluso si un administrador los habilita en el arranque.
/etc/systemd/user Configuración local para todos los usuarios ( systemctl --global enable userunit.service)/usr/lib/systemd/user Unidades de paquetes que se han instalado en todo el sistema para todos los usuarios/run/systemd/user Unidades de tiempo de ejecución
Área gris
Por un lado, el Estándar de jerarquía de archivos especifica que /etces para configuraciones locales que no ejecutan binarios. Por otro lado, especifica que /usr/local/"es para uso del administrador del sistema al instalar el software localmente". También podría argumentar (si no solo con el propósito de la organización) que todos los archivos de la unidad del sistema deberían quedar debajo /usr/local/lib/systemd/system, pero esto está destinado a los archivos de la unidad que son parte del "software" y no de un administrador de paquetes. Las unidades de usuario systemd correspondientes que están en todo el sistema podrían pasar por debajo
/usr/local/lib/systemd/user.
/etc/systemd/systemes donde se pone las secuencias de comandos, pacman paquete de guiones pone en/usr/lib/systemd/systemy para la expediciónsystemctl enable foo.servicecrea enlaces simbólicos a partir/usrde/etc...