Leí que hay dos carpetas para archivos de unidad (no en modo usuario).
/usr/lib/systemd/system/: units provided by installed packages
/etc/systemd/system/: units installed by the system administrator
En conflicto con este entendimiento está la respuesta a esta pregunta:Cómo escribir un script de inicio para Systemd. ¿Alguien puede completar la información que falta para que 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 /etc/systemd/system/ carpeta:
getty.target.wants
multi-user.target.wants
En otro lugar leí que hay otros lugares. 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 coloco los scripts ejecutados por unidades systemd?
Respuesta aceptada:
El mejor lugar para poner sistema archivos de unidad: /etc/systemd/system Solo asegúrese de agregar un objetivo en la sección [Instalar], lea "¿Cómo lo sabe?" para detalles. ACTUALIZAR :/usr/local/lib/systemd/system es otra opción, lea "Área gris" para obtener más detalles".
El mejor lugar para poner usuario archivos de unidad: /etc/systemd/user o $HOME/.config/systemd/user pero depende de los permisos y la situación.
La verdad es que las unidades systemd (o como las llama la oración de introducción, "configuraciones de unidades") pueden ir a cualquier parte. —siempre y cuando esté dispuesto a hacer enlaces simbólicos manuales y sea consciente de las advertencias. Hace la vida más fácil poner la unidad donde systemctl daemon-reload puede encontrarlo por algunas buenas razones:
- Usar una ubicación estándar significa que los generadores systemd los encontrarán y facilitarán su activación en el arranque con
systemctl enable. Esto se debe a que su unidad se agregará automáticamente a un árbol de dependencia de unidades (un caché de unidades). - No necesita pensar en los permisos, porque solo los usuarios privilegiados correctos pueden escribir en las áreas designadas.
¿Cómo lo sabe?
¿Y cómo se habilita exactamente systemctl enable? ¿Sabes dónde crear el enlace simbólico? Lo codifica dentro de la unidad
misma bajo el [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, systemctl enable sabe que esta unidad depende de un grupo de archivos de unidades llamado multi-user.target (“objetivo” es el término utilizado para designar grupos de dependencia de unidades. Puede listar todos los grupos con systemctl list-units --type target ). El grupo de archivos de unidad que se cargará con un objetivo se coloca en un targetname.target.wants directorio. Este es solo un directorio lleno de enlaces simbólicos (o reales). Si su [Install] la sección dice que es WantedBy el multi-user.target , pero si no existe un enlace simbólico en el multi-user.target.wants directorio, entonces no se cargará. Cuando los generadores de unidades systemd agregan su archivo de unidad a la memoria 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ía habilitarlo.
Puntos clave en el Manual:
Es posible que se carguen unidades adicionales en systemd ("vinculadas") desde
directorios que no se encuentran en la ruta de carga de la unidad. Consulte el comando de enlace para
systemctl(1).
En systemctl, busque Comandos de archivo de unidad
Ruta de carga del archivo de unidad
Lea y comprenda la primera oración de la siguiente cita de man systemd.unit (porque implica que es posible que todas las rutas que menciono aquí no se apliquen a usted si su systemd se compiló con diferentes rutas):
Los archivos unitarios se cargan desde un conjunto de rutas determinadas durante la compilación, que se describen en las dos tablas siguientes. Los archivos unitarios encontrados en los directorios enumerados anteriormente anulan los archivos con el mismo nombre en directorios inferiores en la lista.
Cuando la variable $SYSTEMD_UNIT_PATH está establecido, el contenido de esta variable anula la ruta de carga unitaria. Si $SYSTEMD_UNIT_PATH termina con un componente vacío (“:”), la ruta de carga unitaria habitual se agregará al contenido de la variable.
Tabla 1 y Tabla 2 de man systemd.unit son buenos.
Cargar rutas cuando se ejecuta en modo sistema (--system ).
/etc/systemd/systemConfiguración local/run/systemd/systemUnidades de tiempo de ejecución/usr/lib/systemd/systemUnidades de paquetes instalados (o/lib/systemd/systemen algunos casos, leaman systemd.unit)
Cargar ruta cuando se ejecuta en modo de usuario (--user )
Hay una diferencia entre por usuario unidades y todo/global unidades de usuarios.
Dependiente del usuario
-
$XDG_CONFIG_HOME/systemd/userConfiguración de usuario (solo se usa cuando$XDG_CONFIG_HOMEestá configurado) -
$HOME/.config/systemd/userConfiguración de usuario (solo se usa cuando$XDG_CONFIG_HOMEno está configurado) -
$XDG_RUNTIME_DIR/systemd/userUnidades de tiempo de ejecución (solo se usa cuando$XDG_RUNTIME_DIRestá configurado) -
$XDG_DATA_HOME/systemd/userUnidades de paquetes que se han instalado en el directorio de inicio (solo se usa cuando$XDG_DATA_HOMEestá configurado) -
$HOME/.local/share/systemd/userUnidades 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 que también son propiedad de cada usuario. De modo que cada usuario puede detener estos servicios incluso si un administrador los habilita en el arranque.
/etc/systemd/userConfiguración local para todos los usuarios (systemctl --global enable userunit.service)/usr/lib/systemd/userUnidades de paquetes que se han instalado en todo el sistema para todos los usuarios (o/lib/systemd/systemen algunos casos, lea man systemd.unit)/run/systemd/userUnidades de tiempo de ejecución
Área gris
Por un lado, el Estándar de Jerarquía de Archivos especifica que /etc es 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 es solo por motivos de organización) que todos los archivos de la unidad del sistema deberían estar en /usr/local/lib/systemd/system , pero esto está diseñado para archivos de unidad que son parte del "software" y no de un administrador de paquetes.
Las unidades de usuario de systemd correspondientes que son para todo el sistema podrían ir en /usr/local/lib/systemd/user .
Unidad transitoria
¡Otro lugar olvidado no está en ninguna parte! Quizás un programa menos conocido es systemd-run . Puede usarlo para ejecutar unidades transitorias sobre la marcha. ver man systemd-run .
Por ejemplo, para programar un reinicio mañana por la mañana a las 4 a. m. (es posible que necesite --force para asegurarse de que ocurra un reinicio):
systemd-run -u restart --description="Restarts machine" --on-calendar="2020-12-18 00:04:00" systemctl --force reboot
Esto generará un archivo de unidad transitoria restart.service y un temporizador correspondiente (debido al --on-calendar , indicado por transient=yes .
/run/systemd/transient/restart.service
# This is a transient unit file, created programmatically via the systemd API. Do not edit.
[Unit]
Description=Restarts machine
[Service]
ExecStart=
ExecStart="/usr/bin/systemctl" "--force" "reboot"
Tenga en cuenta que también existe la opción de fuerza doble más peligrosa --force --force , que le dice al kernel que se detenga de inmediato (y, si no sabe lo que está haciendo, de manera insegura, porque es casi equivalente a cortar la energía).