Yo leí que hay dos carpetas para los archivos de la unidad (no en modo de usuario).

/usr/lib/systemd/system/: units provided by installed packages
/etc/systemd/system/: units installed by the system administrator

En conflicto con esta comprensión es la siguiente respuesta: https://unix.stackexchange.com/a/47715/33386 . ¿Alguien puede completar la información que falta para que yo entienda lo que está pasando? ( ACTUALIZACIÓN: La respuesta se ha actualizado y mi comprensión ya no entra en conflicto con ella ) .

Además, parece que los scripts están organizados en subcarpetas dentro de la /etc/systemd/system/carpeta:

getty.target.wants
multi-user.target.wants

En otra ubicación leí que hay otras ubicaciones. Parece que estos son para servicios específicos del usuario.

/usr/lib/systemd/user/ where services provided by installed packages go.
/etc/systemd/user/ where system-wide user services are placed by the system administrator.
~/.config/systemd/user/ where the user puts its own services.

Actualización 2015-08-31:

Por el bien de los demás, aquí hay un enlace a una pregunta relacionada que hice recientemente: ¿Dónde pongo los scripts ejecutados por las unidades systemd?

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 pones tus scripts, pacman pone scripts de paquete/usr/lib/systemd/system .

La emisión systemctl enable foo.servicecrea enlaces simbólicos de /usra /etc. Consulte la sección Ruta de carga de la unidad de man systemd.unit(5)para obtener más detalles.

He escrito 3, una para ntpd, una para una segunda, tarjeta ethernet estática, y otra para ejecutar p0f, el identificador pasivo del sistema operativo. Los puse a todos adentro /etc/systemd/system. Parece que tal vez podría dejar que systemdmaneje las cosas de NTP, pero no creo que quiera confiar tanto en ellas.