systemd, init - Gestor de sistemas y servicios systemd
SINOPSIS
/usr/lib/systemd/systemd [OPCIONES...]
init [OPCIONES...]
DESCRIPCIÓN
systemd es un gestor de sistemas y servicios para sistemas operativos Linux. Cuando se ejecuta como el primer proceso al arrancar (como PID 1), actúa como el sistema init que inicia y mantiene los servicios del espacio de usuario. Se inician instancias separadas para los usuarios que han iniciado sesión para iniciar sus servicios.
Normalmente, systemd no se invoca directamente por el usuario, sino que se instala como el enlace simbólico /sbin/init y se inicia durante el arranque temprano. Las instancias del gestor de usuarios se inician automáticamente a través del servicio [email protected](5).
Cuando se ejecuta como una instancia de sistema, systemd interpreta el archivo de configuración system.conf y los archivos de los directorios system.conf.d; cuando se ejecuta como una instancia de usuario, systemd interpreta el archivo de configuración user.conf y los archivos de los directorios user.conf.d. Consulte systemd-system.conf(5) para obtener más información.
systemd contiene implementaciones nativas de varias tareas que deben ejecutarse como parte del proceso de arranque. Por ejemplo, establece el nombre de host o configura el dispositivo de red de bucle invertido. También configura y monta varios sistemas de archivos API, como /sys/, /proc/ y /dev/.
systemd también restablecerá el reloj del sistema durante el arranque temprano si parece que está configurado incorrectamente. Consulte la sección "Época del reloj del sistema" a continuación.
Tenga en cuenta que solo algunas, pero no todas, de las interfaces proporcionadas por systemd están cubiertas por la Promesa de portabilidad y estabilidad de la interfaz[1].
La API de D-Bus de systemd se describe en org.freedesktop.systemd1(5) y org.freedesktop.LogControl1(5).
Los sistemas que invocan systemd en un entorno de contenedor o initrd deben implementar las especificaciones de la Interfaz de contenedor[2] o la Interfaz initrd[3], respectivamente.
UNIDADES
systemd proporciona un sistema de dependencias entre varias entidades denominadas "unidades" de 11 tipos diferentes. Las unidades encapsulan varios objetos que son relevantes para el arranque del sistema y el mantenimiento. La mayoría de las unidades se configuran en archivos de configuración de unidades, cuya sintaxis y conjunto básico de opciones se describen en systemd.unit(5), sin embargo, algunas se crean automáticamente a partir de otros archivos de configuración, dinámicamente a partir del estado del sistema o de forma programática en tiempo de ejecución. Las unidades pueden estar en varios estados, que se describen en la siguiente tabla. Tenga en cuenta que los varios tipos de unidades pueden tener varios subestados adicionales, que se asignan a los estados de unidad generalizados descritos aquí.
Tabla 1. Estados ACTIVO de la unidad
┌──────────────┬─────────────────────────────────────┐
│ Estado │ Descripción │
├──────────────┼─────────────────────────────────────┤
│ activo │ Iniciado, enlazado, conectado, ..., │
│ │ dependiendo del tipo de unidad. │
├──────────────┼─────────────────────────────────────┤
│ inactivo │ Detenido, desenlazado, desconectado, ..., │
│ │ dependiendo del tipo de unidad. │
├──────────────┼─────────────────────────────────────┤
│ fallido │ Similar a inactivo, pero la unidad │
│ │ falló de alguna manera (el proceso │
│ │ devolvió un código de error al salir, │
│ │ se bloqueó, una operación superó el tiempo de espera o │
│ │ después de demasiados reinicios). │
├──────────────┼─────────────────────────────────────┤
│ activando │ Cambiando de inactivo a activo. │
├──────────────┼─────────────────────────────────────┤
│ desactivando │ Cambiando de activo a inactivo. │
├──────────────┼─────────────────────────────────────┤
│ mantenimiento │ La unidad está inactiva y una operación de mantenimiento │
│ │ está en progreso. │
├──────────────┼─────────────────────────────────────┤
│ recargando │ La unidad está activa y está recargando │
│ │ su configuración. │
├──────────────┼─────────────────────────────────────┤
│ actualizando │ La unidad está activa y se está activando una nueva unidad │
│ │ en su espacio de nombres. │
└──────────────┴─────────────────────────────────────┘
Los siguientes tipos de unidades están disponibles:
Unidades de servicio, que inician y controlan demonios y los procesos que los componen. Para obtener más detalles, consulte systemd.service(5).
Unidades de socket, que encapsulan sockets de IPC locales o de red en el sistema, lo que resulta útil para la activación basada en sockets. Para obtener más detalles sobre las unidades de socket, consulte systemd.socket(5); para obtener más detalles sobre la activación basada en sockets y otras formas de activación, consulte daemon(7).
Las unidades de destino son útiles para agrupar unidades o proporcionar puntos de sincronización conocidos durante el
inicio, consulte systemd.target(5).
Las unidades de dispositivo exponen dispositivos del kernel en systemd y pueden usarse para implementar la activación basada en dispositivos. Para obtener más detalles, consulte systemd.device(5).
Las unidades de montaje controlan los puntos de montaje en el sistema de archivos, para obtener más detalles, consulte systemd.mount(5).
Las unidades de automontaje proporcionan capacidades de automontaje, para el montaje bajo demanda de sistemas de archivos, así como para el inicio paralelo. Consulte systemd.automount(5).
Las unidades de temporizador son útiles para activar otras unidades en función de temporizadores. Puede encontrar más detalles en systemd.timer(5).
Las unidades de intercambio son muy similares a las unidades de montaje y encapsulan particiones o archivos de memoria de intercambio del sistema operativo. Se describen en systemd.swap(5).
Las unidades de ruta se pueden utilizar para activar otros servicios cuando los objetos del sistema de archivos cambian o se modifican. Consulte systemd.path(5).
Las unidades de segmento se pueden utilizar para agrupar unidades que administran procesos del sistema (como unidades de servicio y unidades de ámbito) en un árbol jerárquico para fines de administración de recursos. Consulte systemd.slice(5).
Las unidades de ámbito son similares a las unidades de servicio, pero administran procesos externos en lugar de iniciarlos. Consulte systemd.scope(5).
Las unidades se nombran como sus archivos de configuración. Algunas unidades tienen una semántica especial. Se proporciona una lista detallada en systemd.special(7).
systemd conoce varios tipos de dependencias, incluidas las dependencias de requisitos positivos y negativos (es decir, Requires= y Conflicts=), así como las dependencias de ordenación (After= y Before=). NB: las dependencias de ordenación y requisitos son ortogonales. Si existe solo una dependencia de requisito entre dos unidades (por ejemplo, foo.service requiere bar.service), pero no una dependencia de ordenación (por ejemplo, foo.service después de bar.service) y ambas se solicitan para que se inicien, se iniciarán en paralelo. Es un patrón común que se coloquen tanto las dependencias de requisitos como las de ordenación entre dos unidades. Tenga en cuenta también que la mayoría de las dependencias se crean y mantienen implícitamente por systemd. En la mayoría de los casos, no debería ser necesario declarar dependencias adicionales manualmente, sin embargo, es posible hacerlo.
Los programas de aplicación y las unidades (a través de dependencias) pueden solicitar cambios de estado de las unidades. En systemd, estas solicitudes se encapsulan como "trabajos" y se mantienen en una cola de trabajos. Los trabajos pueden tener éxito o pueden fallar, su ejecución se ordena en función de las dependencias de ordenación de las unidades para las que se han programado.
Durante el inicio, systemd activa la unidad de destino default.target, cuyo trabajo es activar los servicios de inicio y otras unidades de inicio extrayéndolos a través de dependencias. Por lo general, el nombre de la unidad es solo un alias (enlace simbólico) para graphical.target (para inicios completos en la interfaz de usuario) o multi-user.target (para inicios de consola limitados para su uso en entornos integrados o de servidor, o similares; un subconjunto de graphical.target). Sin embargo, depende del administrador configurarlo como un alias para cualquier otra unidad de destino. Consulte systemd.special(7) para obtener más detalles sobre estas unidades de destino.
En el primer arranque, systemd habilitará o deshabilitará unidades según la política preestablecida. Consulte systemd.preset(5) y "Semántica del primer arranque" en machine-id(5).
systemd solo mantiene un conjunto mínimo de unidades cargadas en la memoria. Específicamente, las únicas unidades que se mantienen cargadas en la memoria son aquellas para las que se cumple al menos una de las siguientes condiciones:
Está en un estado activo, activando, desactivando o fallido (es decir, en cualquier estado de unidad excepto
"inactivo").
Tiene un trabajo en cola para ella.
Es una dependencia de al menos otra unidad que está cargada en la memoria.
Tiene algún tipo de recurso aún asignado (por ejemplo, una unidad de servicio que está inactiva pero para
la cual todavía existe un proceso que ignoró la solicitud de ser terminado).
Ha sido fijada en la memoria mediante una llamada D-Bus.
systemd cargará automáticamente e implícitamente unidades desde el disco, si aún no están cargadas, tan pronto como se soliciten operaciones para ellas. Por lo tanto, en muchos aspectos, el hecho de que una unidad esté cargada o no es invisible para los clientes. Use systemctl list-units --all para listar de manera exhaustiva todas las unidades que están actualmente cargadas. Cualquier unidad para la cual no se cumple ninguna de las condiciones anteriores se descarga rápidamente. Tenga en cuenta que cuando una unidad se descarga de la memoria, sus datos de contabilidad también se eliminan. Sin embargo, estos datos generalmente no se pierden, ya que se genera un registro del diario que declara los recursos consumidos cada vez que una unidad se cierra.
Los procesos que systemd genera se colocan en grupos de control de Linux individuales, que llevan el nombre de la unidad a la que pertenecen en la jerarquía privada de systemd. (consulte Control Groups v2[4] para obtener más información sobre los grupos de control, o "cgroups" en resumen). systemd utiliza esto para realizar un seguimiento efectivo de los procesos. La información del grupo de control se mantiene en el kernel y es accesible a través de la jerarquía del sistema de archivos (debajo de /sys/fs/cgroup/) o en herramientas como systemd-cgls(1) o ps(1) (ps xawf -eo pid,user,cgroup,args es particularmente útil para enumerar todos los procesos y las unidades de systemd a las que pertenecen).
systemd es compatible con varias funcionalidades Unix establecidas, como /etc/fstab o la base de datos utmp.
systemd tiene un sistema de transacciones mínimo: si se solicita que una unidad se inicie o se cierre, la agregará a ella y a todas sus dependencias a una transacción temporal. Luego, verificará si la
transacción es consistente (es decir, si el orden de todas las unidades no contiene ciclos). Si no lo es, systemd intentará corregirlo y eliminará los trabajos no esenciales de la transacción que puedan eliminar el ciclo. Además, systemd intenta suprimir los trabajos no esenciales en la transacción que detendrían un servicio en ejecución. Finalmente, se verifica si los trabajos de la transacción contradicen los trabajos que ya se han puesto en cola y, opcionalmente, la transacción se aborta. Si todo funciona y la transacción es consistente y se minimiza su impacto, se fusiona con todos los trabajos pendientes y se agrega a la cola de ejecución. En efecto, esto significa que antes de ejecutar una operación solicitada, systemd verificará que tenga sentido, corrigiéndola si es posible, y solo fallará si realmente no puede funcionar.
Tenga en cuenta que las transacciones se generan independientemente del estado de una unidad en tiempo de ejecución; por lo tanto, por ejemplo, si se solicita un trabajo de inicio en una unidad que ya está iniciada, seguirá generando una transacción y activará cualquier dependencia inactiva (y provocará la propagación de otros trabajos según las relaciones definidas). Esto se debe a que el trabajo en cola se compara con el estado de la unidad de destino en el momento de la ejecución y se marca como exitoso y completo cuando ambos cumplen los requisitos. Sin embargo, este trabajo también incluye otras dependencias debido a las relaciones definidas y, por lo tanto, conduce, en nuestro ejemplo, a que se pongan en cola trabajos de inicio para cualquiera de esas unidades inactivas.
Las unidades se pueden generar dinámicamente en el momento del arranque y la recarga del administrador del sistema, por ejemplo, en función de otros archivos de configuración o parámetros pasados en la línea de comandos del kernel. Para obtener más detalles, consulte systemd.generator(7).
DIRECTORIOS
Directorios de unidades del sistema El administrador del sistema systemd lee la configuración de las unidades de varios directorios. Los paquetes que desean instalar archivos de unidad deben colocarlos en el directorio devuelto por pkg-config systemd --variable=systemdsystemunitdir. Otros directorios que se verifican son /usr/local/lib/systemd/system y /usr/lib/systemd/system. La configuración del usuario siempre tiene prioridad. pkg-config systemd --variable=systemdsystemconfdir devuelve la ruta del directorio de configuración del sistema. Los paquetes solo deben modificar el contenido de estos directorios con los comandos enable y disable de la herramienta systemctl(1). La lista completa de directorios se proporciona en systemd.unit(5).
Directorios de unidades de usuario Se aplican reglas similares a los directorios de unidades de usuario. Sin embargo, aquí se sigue la especificación XDG Base Directory[5] para encontrar las unidades. Las aplicaciones deben colocar sus archivos de unidad en el directorio devuelto por pkg-config systemd --variable=systemduserunitdir. La configuración global se realiza en el directorio informado por pkg-config systemd --variable=systemduserconfdir. Los comandos enable y disable de la herramienta systemctl(1) pueden manejar tanto la habilitación/deshabilitación global (es decir, para todos los usuarios) como la privada (para un solo usuario) de las unidades. La lista completa de directorios se proporciona en systemd.unit(5).
SEÑALES
El servicio escucha varias señales de proceso UNIX que se pueden utilizar para solicitar diversas acciones de forma asíncrona. El manejo de señales se habilita muy temprano durante el arranque, antes de que se invoquen más procesos. Sin embargo, un administrador de contenedores supervisor o similar que tenga la intención de solicitar estas operaciones a través de este mecanismo debe tener en cuenta que esta funcionalidad no está disponible durante la fase de inicialización más temprana. Se emite un mensaje de notificación sd_notify() que contiene el campo X_SYSTEMD_SIGNALS_LEVEL=2 una vez que se habilitan los controladores de señales, consulte a continuación. Esto se puede utilizar para programar correctamente la presentación de estas señales.
SIGTERM
Cuando recibe esta señal, el administrador del sistema systemd serializa su estado, se vuelve a ejecutar y deserializa el estado guardado. Esto es casi equivalente a systemctl daemon-reexec.
Los administradores de sistema systemd iniciarán la unidad `exit.target` cuando reciban esta señal. Esto es casi equivalente a `systemctl --user start exit.target --job-mode=replace-irreversibly`.
SIGINT
Cuando recibe esta señal, el administrador del sistema systemd iniciará la unidad ctrl-alt-del.target. Esto es casi equivalente a systemctl start ctrl-alt-del.target --job-mode=replace-irreversibly. Si esta señal se recibe más de 7 veces en 2 segundos, se activa un reinicio inmediato. Tenga en cuenta que presionar Ctrl+Alt+Supr en la consola activará esta señal. Por lo tanto, si un reinicio se está bloqueando, presionar Ctrl+Alt+Supr más de 7 veces en 2 segundos es una forma relativamente segura de activar un reinicio inmediato.
Los administradores de sistema systemd tratan esta señal de la misma manera que SIGTERM.
SIGWINCH
Cuando se recibe esta señal, el administrador del sistema systemd iniciará la unidad kbrequest.target. Esto es casi equivalente a systemctl start kbrequest.target.
Esta señal es ignorada por los administradores de sistema systemd.
SIGPWR
Cuando se recibe esta señal, el administrador systemd iniciará la unidad sigpwr.target. Esto es casi equivalente a systemctl start sigpwr.target.
SIGUSR1
Cuando se recibe esta señal, el administrador systemd intentará reconectarse al bus D-Bus.
SIGUSR2
Cuando se recibe esta señal, el administrador systemd registrará su estado completo en un formato legible por humanos. Los datos registrados son los mismos que se imprimen con systemd-analyze dump.
SIGHUP
Recarga la configuración completa del demonio. Esto es casi equivalente a systemctl daemon-reload.
SIGRTMIN+0
Entra en modo predeterminado, inicia la unidad default.target. Esto es casi equivalente a systemctl isolate default.target.
SIGRTMIN+1
Entra en modo de rescate, inicia la unidad rescue.target. Esto es casi equivalente a systemctl isolate rescue.target.
SIGRTMIN+2
Entra en modo de emergencia, inicia la unidad emergency.service. Esto es casi equivalente a systemctl isolate emergency.service.
SIGRTMIN+3
Detiene la máquina, inicia la unidad halt.target. Esto es casi equivalente a systemctl start halt.target --job-mode=replace-irreversibly.
SIGRTMIN+4
Apaga la máquina, inicia la unidad poweroff.target. Esto es casi equivalente a systemctl start poweroff.target --job-mode=replace-irreversibly.
SIGRTMIN+5
Reinicia la máquina, inicia la unidad reboot.target. Esto es casi equivalente a systemctl start reboot.target --job-mode=replace-irreversibly.
SIGRTMIN+6
Reinicia la máquina a través de kexec, inicia la unidad kexec.target. Esto es casi equivalente a systemctl start kexec.target --job-mode=replace-irreversibly.
SIGRTMIN+7
Reinicia el espacio de usuario, inicia la unidad soft-reboot.target. Esto es en su mayoría equivalente a systemctl start soft-reboot.target --job-mode=replace-irreversibly.
Agregado en la versión 254.
SIGRTMIN+13
Detiene inmediatamente la máquina.
SIGRTMIN+14
Apaga inmediatamente la máquina.
SIGRTMIN+15
Reinicia inmediatamente la máquina.
SIGRTMIN+16
Reinicia inmediatamente la máquina con kexec.
SIGRTMIN+17
Reinicia inmediatamente el espacio de usuario.
Agregado en la versión 254.
SIGRTMIN+20
Habilita la visualización de mensajes de estado en la consola, como se controla mediante systemd.show_status=1 en la línea de comandos del kernel.
Es posible que desee usar SetShowStatus() en lugar de SIGRTMIN+20 para evitar condiciones de carrera. Consulte org.freedesktop.systemd1(5).
SIGRTMIN+21
Deshabilita la visualización de mensajes de estado en la consola, como se controla mediante systemd.show_status=0 en la línea de comandos del kernel.
Es posible que desee usar SetShowStatus() en lugar de SIGRTMIN+21 para evitar condiciones de carrera. Consulte org.freedesktop.systemd1(5).
SIGRTMIN+22
Establece el nivel de registro del administrador de servicios en "debug", de una manera equivalente a systemd.log_level=debug en la línea de comandos del kernel.
SIGRTMIN+23
Restaura el nivel de registro a su valor configurado. El valor configurado se deriva, en orden de prioridad, del valor especificado con systemd.log-level= en la línea de comandos del kernel, o del valor especificado con LogLevel= en el archivo de configuración, o del valor predeterminado integrado de "info".
Agregado en la versión 239.
SIGRTMIN+24
Sale inmediatamente del administrador (solo disponible para instancias --user).
Agregado en la versión 195.
SIGRTMIN+25
Al recibir esta señal, el administrador systemd se reejecutará. Esto es en su mayoría equivalente a systemctl daemon-reexec, excepto que se hará de forma asíncrona.
El administrador del sistema systemd trata esta señal de la misma manera que SIGTERM.
Agregado en la versión 250.
SIGRTMIN+26
Restaura el destino de registro a su valor configurado. El valor configurado se deriva, en orden de prioridad, del valor especificado con systemd.log-target= en la línea de comandos del kernel, o del valor especificado con LogTarget= en el archivo de configuración, o del valor predeterminado.
Agregado en la versión 239.
SIGRTMIN+27, SIGRTMIN+28
Establece el destino de registro en "console" con SIGRTMIN+27 (o "kmsg" con SIGRTMIN+28), de una manera equivalente a systemd.log_target=console (o systemd.log_target=kmsg con SIGRTMIN+28) en la línea de comandos del kernel.
Agregado en la versión 239.
ENTORNO
El bloque de entorno para el administrador del sistema se establece inicialmente mediante el kernel. (En particular, las asignaciones "clave=valor" en la línea de comandos del kernel se convierten en variables de entorno para PID 1. Para el administrador de usuario, el administrador del sistema establece el entorno como se describe en la sección "Variables de entorno en los procesos generados" de systemd.exec(5). La configuración DefaultEnvironment= en el administrador del sistema se aplica a todos los servicios, incluido [email protected]. Se pueden configurar entradas adicionales (como para cualquier otro servicio) a través de la configuración Environment= y EnvironmentFile= para [email protected] (vea systemd.exec(5)). Además, se pueden establecer variables de entorno adicionales a través de la configuración ManagerEnvironment= en systemd-system.conf(5) y systemd-user.conf(5).
Algunas de las variables que entiende systemd:
$SYSTEMD_LOG_LEVEL
El nivel de registro máximo de los mensajes emitidos (los mensajes con un nivel de registro más alto, es decir, menos importantes, se suprimirán). Acepta una lista separada por comas de valores. Un valor puede ser uno de los siguientes (en orden de importancia decreciente): emerg, alert, crit, err, warning, notice, info, debug, o un entero en el rango 0...7. Consulte syslog(3) para obtener más información. Cada valor puede tener opcionalmente como prefijo uno de console, syslog, kmsg o journal seguido de dos puntos para establecer el nivel de registro máximo para ese destino de registro específico (por ejemplo, SYSTEMD_LOG_LEVEL=debug,console:info especifica registrar al nivel de depuración, excepto cuando se registra en la consola, que debe estar en el nivel de información). Tenga en cuenta que el nivel de registro máximo global tiene prioridad sobre cualquier nivel de registro máximo por destino.
Esto se puede anular con --log-level=.
$SYSTEMD_LOG_COLOR
Un valor booleano. Si es verdadero, los mensajes escritos en la tty se colorearán según la prioridad.
Esto se puede anular con --log-color=.
$SYSTEMD_LOG_TIME
Un valor booleano. Si es verdadero, los mensajes de registro de la consola tendrán como prefijo una marca de tiempo.
Esto se puede anular con --log-time=.
Agregado en la versión 246.
$SYSTEMD_LOG_LOCATION
Un valor booleano. Si es verdadero, los mensajes tendrán como prefijo el nombre de archivo y el número de línea en el código fuente donde se origina el mensaje.
Esto se puede anular con --log-location=.
$SYSTEMD_LOG_TID
Un valor booleano. Si es verdadero, los mensajes tendrán como prefijo el ID de hilo numérico actual (TID).
Agregado en la versión 247.
$SYSTEMD_LOG_TARGET
El destino de los mensajes de registro. Uno de: console (registrar en la tty adjunta), console-prefixed (registrar en la tty adjunta, pero con prefijos que codifican el nivel de registro y la "instalación", consulte syslog(3)), kmsg (registrar en el búfer de registro circular del kernel), journal (registrar en el diario), journal-or-kmsg (registrar en el diario si está disponible, y en kmsg en caso contrario), auto (determinar el destino de registro apropiado automáticamente, el valor predeterminado), null (deshabilitar la salida de registro).
Esto se puede anular con --log-target=.
$SYSTEMD_LOG_RATELIMIT_KMSG
Indica si se debe limitar la velocidad de kmsg o no. Acepta un valor booleano. El valor predeterminado es "true". Si se deshabilita, systemd no limitará la velocidad de los mensajes escritos en kmsg.
Agregado en la versión 254.
$XDG_CONFIG_HOME, $XDG_CONFIG_DIRS, $XDG_DATA_HOME, $XDG_DATA_DIRS
El administrador de usuarios de systemd utiliza estas variables de acuerdo con la especificación XDG Base Directory[5] para encontrar su configuración.
$SYSTEMD_UNIT_PATH, $SYSTEMD_GENERATOR_PATH, $SYSTEMD_ENVIRONMENT_GENERATOR_PATH
Controla dónde busca systemd los archivos de unidad y los generadores.
Estas variables pueden contener una lista de rutas, separadas por dos puntos (":"). Cuando se establece, si la lista termina con un componente vacío ("...:"), esta lista se antepone al conjunto habitual de rutas. De lo contrario, la lista especificada reemplaza el conjunto habitual de rutas.
$SYSTEMD_PAGER, $PAGER
Paginador que se utiliza cuando no se especifica la opción --no-pager. Se utiliza $SYSTEMD_PAGER si está definido; de lo contrario, se utiliza $PAGER. Si ni $SYSTEMD_PAGER ni $PAGER están definidos, se prueba una serie de paginadores conocidos en orden, incluyendo [less]({filename}../../less)(1) y more(1), hasta que se encuentra uno. Si no se encuentra ningún paginador, no se invoca ningún paginador. Establecer estas variables de entorno a una cadena vacía o al valor "cat" es equivalente a pasar la opción --no-pager.
Nota: si $SYSTEMD_PAGERSECURE no está definido, $SYSTEMD_PAGER y $PAGER solo se pueden utilizar para deshabilitar el paginador (con "cat" o ""), y de lo contrario se ignoran.
$SYSTEMD_LESS
Anula las opciones que se pasan a less (por defecto "FRSXMK").
Los usuarios pueden querer cambiar dos opciones en particular:
K
Esta opción indica al paginador que salga inmediatamente cuando se presiona Ctrl+C. Para permitir que less maneje Ctrl+C por sí mismo y vuelva al indicador de comandos del paginador, desactive esta opción.
Si el valor de $SYSTEMD_LESS no incluye "K", y el paginador que se invoca es less, Ctrl+C será ignorado por el ejecutable y deberá ser manejado por el paginador.
X
Esta opción indica al paginador que no envíe cadenas de inicialización y desinicialización de termcap al terminal. Se establece por defecto para permitir que la salida del comando permanezca visible en el terminal incluso después de que el paginador salga. Sin embargo, esto impide que algunas funcionalidades del paginador funcionen, en particular, la salida paginada no se puede desplazar con el ratón.
Tenga en cuenta que establecer la variable de entorno $LESS normal no tiene ningún efecto para las invocaciones de less por parte de las herramientas systemd.
Consulte [less]({filename}../../less)(1) para obtener más información.
$SYSTEMD_LESSCHARSET
Anula el conjunto de caracteres que se pasa a less (por defecto "utf-8", si se determina que el terminal que lo invoca es compatible con UTF-8).
Tenga en cuenta que establecer la variable de entorno $LESSCHARSET normal no tiene ningún efecto para las invocaciones de less por parte de las herramientas systemd.
$SYSTEMD_PAGERSECURE
Los comandos comunes del paginador, como [less]({filename}../../less)(1), además de "paginar", es decir, desplazarse por la salida, admiten la apertura o escritura de otros archivos y la ejecución de comandos de shell arbitrarios. Cuando los comandos se invocan con privilegios elevados, por ejemplo, con [sudo]({filename}../../sudo)(8) o pkexec(1), el paginador se convierte en un límite de seguridad. Se debe tener cuidado de que solo se utilicen programas con una funcionalidad estrictamente limitada como paginadores, y no se deben permitir funciones interactivas no deseadas, como la apertura o creación de nuevos archivos o el inicio de subprocesos. El "modo seguro" para el paginador se puede habilitar como se describe a continuación, si el paginador lo admite (la mayoría de los paginadores no están escritos de manera que tengan esto en cuenta). Se recomienda habilitar explícitamente el "modo seguro" o deshabilitar completamente el paginador mediante la opción --no-pager o PAGER=cat cuando se permite que usuarios no confiables ejecuten comandos con privilegios elevados.
Esta opción acepta un argumento booleano. Cuando se establece en verdadero, se habilita el "modo seguro" del paginador. En el "modo seguro", se establecerá LESSSECURE=1 al invocar el paginador, lo que indica al paginador que desactive los comandos que abren o crean archivos nuevos o inician nuevos subprocesos. Actualmente, solo less(1) se sabe que entiende esta variable e implementa el "modo seguro".
Cuando se establece en falso, no se aplica ninguna limitación al paginador. Establecer SYSTEMD_PAGERSECURE=0 o no eliminarlo del entorno heredado puede permitir que el usuario invoque comandos arbitrarios.
Cuando $SYSTEMD_PAGERSECURE no está establecido, las herramientas systemd intentan determinar automáticamente si se debe habilitar el "modo seguro" y si el paginador lo admite. El "modo seguro" se habilita si el ID de usuario efectivo no es el mismo que el propietario de la sesión de inicio de sesión, consulte geteuid(2) y sd_pid_get_owner_uid(3), o cuando se ejecuta bajo sudo(8) u otras herramientas similares ($SUDO_UID está establecido [6]). En esos casos, se establecerá SYSTEMD_PAGERSECURE=1 y los paginadores que no se sabe que implementan el "modo seguro" no se utilizarán. Tenga en cuenta que esta detección automática solo cubre los mecanismos más comunes para elevar los privilegios y está destinada a ser una conveniencia. Se recomienda establecer explícitamente $SYSTEMD_PAGERSECURE o deshabilitar el paginador.
Tenga en cuenta que si se deben respetar las variables $SYSTEMD_PAGER o $PAGER, aparte de deshabilitar el paginador, también se debe establecer $SYSTEMD_PAGERSECURE.
$SYSTEMD_COLORS
Acepta un argumento booleano. Cuando es verdadero, systemd y las utilidades relacionadas utilizarán colores en su salida; de lo contrario, la salida será monocromática. Además, la variable puede tomar uno de los siguientes valores especiales: "16", "256" para restringir el uso de colores a los 16 o 256 colores ANSI básicos, respectivamente. Esto se puede especificar para anular la decisión automática basada en $TERM y la conexión del terminal.
$SYSTEMD_URLIFY
El valor debe ser booleano. Controla si se deben generar enlaces clickeables en la salida para los emuladores de terminal que admiten esto. Esto se puede especificar para anular la decisión que toma systemd en función de $TERM y otras condiciones.
$LISTEN_PID, $LISTEN_PIDFDID, $LISTEN_FDS, $LISTEN_FDNAMES
Establecido por systemd para los procesos supervisados durante la activación basada en sockets. Consulte sd_listen_fds(3) para obtener más información.
$NOTIFY_SOCKET
Establecido por el administrador de servicios para sus servicios, para las notificaciones de estado y preparación. También lo utiliza el administrador de servicios para notificar a los administradores de contenedores o administradores de servicios superiores en la pila sobre su progreso. Consulte sd_notify(3) y la sección relevante a continuación para obtener más información.
Para obtener más información sobre las variables de entorno que utiliza systemd y sus diversos componentes, consulte Variables de entorno conocidas[7].
LÍNEA DE COMANDOS DEL NÚCLEO
Cuando se ejecuta como la instancia del sistema, systemd analiza varias opciones que se enumeran a continuación. Se pueden especificar como argumentos de la línea de comandos del núcleo, que se analizan a partir de varias fuentes, según el entorno en el que se ejecuta systemd. Si se ejecuta dentro de un contenedor de Linux, estas opciones se analizan a partir de los argumentos de la línea de comandos que se pasan a systemd, junto con cualquier opción de la línea de comandos que se enumera en la sección Opciones anterior. Si se ejecuta fuera de los contenedores de Linux, estos argumentos se analizan a partir de /proc/cmdline.
Las siguientes variables se entienden:
systemd.unit=, rd.systemd.unit=
Anula la unidad que se activará al arrancar. El valor predeterminado es default.target. Esto se puede utilizar para arrancar temporalmente en una unidad de arranque diferente, por ejemplo, rescue.target o emergency.service. Consulte systemd.special(7) para obtener más detalles sobre estas unidades. La opción con el prefijo "rd." solo se aplica en el initrd, mientras que la que no tiene prefijo solo se aplica en el sistema principal.
systemd.dump_core
Acepta un argumento booleano o habilita la opción si se especifica sin un argumento. Si está habilitada, el administrador systemd (PID 1) genera un archivo core cuando se bloquea. De lo contrario, no se crea ningún archivo core. El valor predeterminado es habilitado.
Agregado en la versión 233.
systemd.crash_chvt
Acepta un entero positivo o un argumento booleano. También se puede especificar sin un argumento, con el mismo efecto que un booleano positivo. Si se especifica un entero positivo (en el rango de 1 a 63), el administrador del sistema (PID 1) activará la terminal virtual especificada cuando se bloquee. El valor predeterminado es deshabilitado, lo que significa que no se intentará ningún cambio. Si se establece en habilitado, se utilizará la terminal virtual a la que se escriben los mensajes del kernel en su lugar.
Agregado en la versión 233.
systemd.crash_shell
Acepta un argumento booleano o habilita la opción si se especifica sin un argumento. Si está habilitado, el administrador del sistema (PID 1) genera un shell cuando se bloquea. De lo contrario, no se genera ningún shell. El valor predeterminado es deshabilitado, por motivos de seguridad, ya que el shell no está protegido por la autenticación con contraseña.
Agregado en la versión 233.
systemd.crash_action=
Acepta uno de los valores "freeze", "reboot" o "poweroff". El valor predeterminado es "freeze". Si se establece en "freeze", el sistema se bloqueará indefinidamente cuando el administrador del sistema (PID 1) se bloquee. Si se establece en "reboot", el administrador del sistema (PID 1) reiniciará la máquina automáticamente cuando se bloquee, después de una demora de 10 segundos. Si se establece en "poweroff", el administrador del sistema (PID 1) apagará la máquina inmediatamente cuando se bloquee. Si se combina con systemd.crash_shell, la acción de bloqueo configurada se ejecutará después de que el shell se cierre.
Agregado en la versión 256.
systemd.confirm_spawn
Acepta un argumento booleano o una ruta al terminal virtual donde se deben emitir los mensajes de confirmación. También se puede especificar sin un argumento, con el mismo efecto que un booleano positivo. Si está habilitado, el administrador del sistema (PID 1) solicita confirmación al generar procesos utilizando /dev/console. Si se proporciona una ruta o un nombre de consola (como "ttyS0"), se utilizará la terminal virtual a la que apunta esta ruta o que describe el nombre dado en su lugar. El valor predeterminado es deshabilitado.
Añadido en la versión 233.
systemd.service_watchdogs=
Acepta un argumento booleano. Si se deshabilita, todos los watchdogs de tiempo de ejecución de los servicios (WatchdogSec=) y las acciones de emergencia (por ejemplo, OnFailure= o StartLimitAction=) se ignoran por parte del administrador del sistema (PID 1); consulte systemd.service(5). Por defecto, está habilitado, es decir, los watchdogs y las acciones de error se procesan normalmente. El watchdog de hardware no se ve afectado por esta opción.
Añadido en la versión 237.
systemd.show_status
Acepta un argumento booleano o las constantes error y auto. También se puede especificar sin un argumento, con el mismo efecto que un booleano positivo. Si se habilita, el administrador de systemd (PID 1) muestra actualizaciones breves del estado del servicio en la consola durante el inicio. Con error, solo se muestran los mensajes sobre los fallos, pero el inicio es silencioso. auto se comporta como falso hasta que hay un retraso significativo en el inicio. Por defecto, está habilitado, a menos que se pase quiet como opción de la línea de comandos del kernel, en cuyo caso por defecto es error. Si se especifica, anula la opción de configuración del archivo del administrador del sistema ShowStatus=, consulte systemd-system.conf(5).
Añadido en la versión 233.
systemd.status_unit_format=
Acepta name, description o combined como valor. Si es name, el administrador del sistema utilizará los nombres de las unidades en los mensajes de estado. Si es combined, el administrador del sistema utilizará los nombres de las unidades y la descripción en los mensajes de estado. Cuando se especifica, anula la opción de configuración del archivo del administrador del sistema StatusUnitFormat=, consulte systemd-system.conf(5).
Añadido en la versión 243.
systemd.log_color, systemd.log_level=, systemd.log_location, systemd.log_target=,
systemd.log_time, systemd.log_tid, systemd.log_ratelimit_kmsg
Controla la salida del registro, con el mismo efecto que las variables de entorno $SYSTEMD_LOG_COLOR, $SYSTEMD_LOG_LEVEL,
$SYSTEMD_LOG_LOCATION, $SYSTEMD_LOG_TARGET, $SYSTEMD_LOG_TIME, $SYSTEMD_LOG_TID y
$SYSTEMD_LOG_RATELIMIT_KMSG descritas anteriormente. systemd.log_color,
systemd.log_location, systemd.log_time, systemd.log_tid y systemd.log_ratelimit_kmsg se pueden
especificar sin un argumento, con el mismo efecto que un booleano positivo.
systemd.default_standard_output=, systemd.default_standard_error=
Controla la salida estándar y de error por defecto para los servicios y sockets. Es decir, controla el valor por defecto para StandardOutput= y StandardError= (consulte systemd.exec(5) para obtener más detalles). Acepta uno de inherit, null, tty, journal, journal+console, kmsg, kmsg+console. Si se omite el argumento, systemd.default-standard-output= tiene por defecto journal y systemd.default-standard-error= tiene por defecto inherit.
systemd.setenv=
Acepta un argumento de cadena en el formato VARIABLE=VALUE. Se puede utilizar para establecer variables de entorno predeterminadas que se añadirán a los procesos hijo bifurcados. Se puede utilizar más de una vez para establecer varias variables.
systemd.machine_id=
Acepta un valor hexadecimal de 32 caracteres que se utilizará para establecer el machine-id. Está pensado principalmente para el arranque en red, donde se desea el mismo machine-id para cada arranque.
Agregado en la versión 229.
systemd.set_credential=, systemd.set_credential_binary=
Establece una credencial del sistema, que luego se puede propagar a los servicios del sistema utilizando la configuración ImportCredential= o LoadCredential=, consulte systemd.exec(5) para obtener más detalles. Toma un par de nombre de credencial y valor, separados por dos puntos. El parámetro systemd.set\_credential= espera el valor de la credencial en forma de texto literal, el parámetro systemd.set\_credential\_binary= toma datos binarios codificados en Base64. Tenga en cuenta que la línea de comandos del kernel suele ser accesible para los programas no privilegiados en /proc/cmdline. Por lo tanto, este mecanismo no es adecuado para transferir datos confidenciales. Úselo solo para datos que no sean confidenciales (por ejemplo, claves públicas/certificados, en lugar de claves privadas) o en entornos de prueba/depuración.
Para obtener más información, consulte la documentación [Credenciales del sistema y del servicio].
Agregado en la versión 251.
systemd.import_credentials=
Toma un argumento booleano. Si es falso, desactiva la importación de credenciales desde la línea de comandos del kernel, la tabla OEM de DMI/SMBIOS, el subsistema qemu_fw_cfg o el programa de inicio de EFI.
Agregado en la versión 251.
quiet
Desactiva la salida de estado durante el arranque, de forma similar a como lo haría systemd.show\_status=no. Tenga en cuenta que esta opción también la lee el propio kernel y desactiva la salida del registro del kernel. Pasar esta opción, por lo tanto, desactiva la salida habitual tanto del administrador del sistema como del kernel.
Agregado en la versión 186.
debug
Activa la salida de depuración. Esto es equivalente a systemd.log\_level=debug. Tenga en cuenta que esta opción también la lee el propio kernel y activa la salida de depuración del kernel. Pasar esta opción, por lo tanto, activa la salida de depuración tanto del administrador del sistema como del kernel.
Agregado en la versión 205.
emergency, rd.emergency, -b
Arranca en modo de emergencia. Esto es equivalente a systemd.unit=emergency.target o rd.systemd.unit=emergency.target, respectivamente, y se proporciona por razones de compatibilidad y para que sea más fácil de escribir.
Agregado en la versión 186.
rescue, rd.rescue, single, s, S, 1
Arranca en modo de rescate. Esto es equivalente a systemd.unit=rescue.target o rd.systemd.unit=rescue.target, respectivamente, y se proporciona por razones de compatibilidad y para que sea más fácil de escribir.
Agregado en la versión 186.
2 3, 4, 5
Arranca en el nivel de ejecución SysV heredado especificado. 2, 3 y 4 son equivalentes a systemd.unit=multi-user.target; y 5 es equivalente a systemd.unit=graphical.target, y se proporcionan por razones de compatibilidad y para que sea más fácil de escribir.
Agregado en la versión 186.
locale.LANG=, locale.LANGUAGE=, locale.LC_CTYPE=, locale.LC_NUMERIC=, locale.LC_TIME=,
locale.LC_COLLATE=, locale.LC_MONETARY=, locale.LC_MESSAGES=, locale.LC_PAPER=, locale.LC_NAME=,
locale.LC_ADDRESS=, locale.LC_TELEPHONE=, locale.LC_MEASUREMENT=, locale.LC_IDENTIFICATION=
Establece la configuración regional del sistema a utilizar. Esto anula la configuración en /etc/locale.conf. Para obtener más información, consulte locale.conf(5) y locale(7).
Agregado en la versión 186.
Para obtener información sobre otros parámetros de la línea de comandos del kernel que utilizan los componentes del sistema operativo principal, consulte kernel-command-line(7).
CREDENCIALES DEL SISTEMA
Durante la inicialización, el gestor de servicios importará credenciales de varias fuentes al conjunto de credenciales del sistema, que luego se pueden propagar a los servicios y utilizar por los generadores:
Cuando el gestor de servicios se inicializa por primera vez, leerá las credenciales del sistema de las cadenas de SMBIOS Tipo 11, io.systemd.credential:name=value, y io.systemd.credential.binary:name=value.
Al mismo tiempo, importará las credenciales de QEMU "fw_cfg". (Tenga en cuenta que el mecanismo SMBIOS generalmente es preferible, porque es más rápido y genérico).
Las credenciales se pueden pasar a través de la línea de comandos del kernel, utilizando el parámetro systemd.set-credential=, como se indica arriba.
Las credenciales se pueden pasar desde el entorno UEFI a través de systemd-stub(7).
Cuando el gestor de servicios se invoca durante la transición de initrd a host, importará todos los archivos en /run/credentials/@initrd/ como credenciales del sistema.
Invoque systemd-creds(1) de la siguiente manera para ver la lista de credenciales que se pasan al sistema:
# systemd-creds --system list
Para obtener más información, consulte la documentación de System and Service Credentials[8].
El gestor de servicios, cuando se ejecuta como PID 1, consume las siguientes credenciales del sistema:
vmm.notify_socket
Contiene una dirección AF_VSOCK o AF_UNIX donde se debe enviar un mensaje de notificación READY=1 cuando el gestor de servicios haya completado el arranque. Consulte sd_notify(3) y la siguiente sección para obtener más información. Tenga en cuenta que, en caso de que el hipervisor no admita SOCK_DGRAM sobre AF_VSOCK, se intentará SOCK_SEQPACKET en su lugar. La carga útil de credenciales para AF_VSOCK debe ser una cadena en el formato "vsock:CID:PORT". Se pueden usar "vsock-stream", "vsock-dgram" y "vsock-seqpacket" en lugar de "vsock" para forzar el uso del tipo de socket correspondiente.
Esta característica es útil para los administradores de máquinas u otros procesos en el host para recibir una notificación a través de VSOCK cuando una máquina virtual ha terminado de arrancar.
Agregado en la versión 254.
system.machine_id
Toma un ID hexadecimal de 128 bits para inicializar /etc/machine-id, si el archivo aún no está configurado. Consulte machine-id(5) para obtener más detalles.
Agregado en la versión 254.
Para obtener una lista de las credenciales del sistema que consumen varios otros componentes de systemd, consulte systemd.systemcredentials(7).
PROTOCOLO DE PREPARACIÓN
El gestor de servicios implementa un protocolo de notificación de preparación tanto entre el gestor y sus servicios (es decir, hacia abajo en la pila), como entre el gestor y un supervisor potencial más arriba en la pila (este último podría ser un administrador de máquinas o contenedores, o en el caso de un gestor de servicios por usuario, la instancia del gestor de servicios del sistema). El protocolo básico (y la API sugerida para él) se describe en sd_notify(3).
El socket de notificación que el gestor de servicios (incluido PID 1) utiliza para informar sobre la preparación a su propio supervisor se establece a través de la variable de entorno $NOTIFY_SOCKET habitual (consulte arriba). Dado que esto se puede configurar directamente solo para los administradores de contenedores y para la instancia por usuario del gestor de servicios, existe un mecanismo adicional para configurar esto, en particular destinado a usarse en entornos de máquina virtual: la credencial del sistema vmm.notify_socket (consulte arriba) se puede establecer en un socket adecuado (típicamente uno AF_VSOCK) a través de cadenas de proveedor de SMBIOS Tipo 11. Para obtener más detalles, consulte arriba.
El protocolo de notificación del administrador de servicios hacia la capa superior, que utiliza el supervisor, admite una serie de campos de extensión que permiten al supervisor obtener información sobre propiedades específicas del sistema y realizar un seguimiento del progreso del arranque. En concreto, se envían los siguientes campos:
Se enviará un mensaje X_SYSTEMD_HOSTNAME=... una vez que se haya determinado el nombre de host inicial del sistema. Tenga en cuenta que, durante el tiempo de ejecución posterior, el nombre de host puede volver a cambiarse mediante programación, y (actualmente) no se envían más notificaciones en ese caso.
Añadido en la versión 256.
Se enviará un mensaje X_SYSTEMD_MACHINE_ID=... una vez que se haya determinado el ID de máquina del sistema. Consulte machine-id(5) para obtener más detalles.
Añadido en la versión 256.
Se enviará un mensaje X_SYSTEMD_SIGNALS_LEVEL=... una vez que el administrador de servicios haya instalado los diversos controladores de señales de procesos UNIX descritos anteriormente. El valor del campo es un entero sin signo con formato de cadena decimal, e indica el nivel de característica de la señal de proceso UNIX admitida por el administrador de servicios. Actualmente, solo se define un nivel de característica:
X_SYSTEMD_SIGNALS_LEVEL=2 cubre las diversas señales de proceso UNIX documentadas anteriormente, que son un superconjunto de las admitidas por el sistema SysV init histórico.
Las señales enviadas al PID 1 antes de que se envíe este mensaje pueden no manejarse correctamente. Un consumidor de estos mensajes debe analizar el valor como un entero sin signo que indica el nivel de compatibilidad. Por ahora, solo se define el nivel mencionado 2, pero más adelante se pueden definir niveles adicionales con enteros más altos, que implementarán un superconjunto del comportamiento definido actualmente.
Añadido en la versión 256.
Se enviarán mensajes X_SYSTEMD_UNIT_ACTIVE=... y X_SYSTEMD_UNIT_INACTIVE=... para cada unidad de destino a medida que se active o deje de estar activa. Esto es útil para realizar un seguimiento del progreso del arranque y la funcionalidad. Por ejemplo, una vez que se informa de que la unidad ssh-access.target ha comenzado, normalmente el acceso SSH estará disponible; consulte systemd.special(7) para obtener más detalles.
Añadido en la versión 256.
Se enviará un mensaje X_SYSTEMD_SHUTDOWN=... poco antes de que el sistema se apague. El valor es una de las cadenas "reboot", "halt", "poweroff" y "kexec", e indica qué tipo de apagado se está ejecutando.
Añadido en la versión 256.
También se enviará un mensaje X_SYSTEMD_REBOOT_PARAMETER=... poco antes de que el sistema se apague. Su valor es el argumento de reinicio, tal como se configura con systemctl --reboot-argument=....
Añadido en la versión 256.
Tenga en cuenta que estos campos de extensión se envían además de las notificaciones "READY=1" y "RELOADING=1" habituales.
OPCIONES
systemd se invoca directamente con muy poca frecuencia, ya que se inicia al principio y ya está en ejecución cuando los usuarios pueden interactuar con él. Normalmente, se utilizan herramientas como systemctl(1) para enviar comandos al administrador. Dado que systemd normalmente no se invoca directamente, las opciones que se indican a continuación son principalmente útiles para la depuración y fines especiales.
Opciones de introspección y depuración
Estas opciones se utilizan para pruebas e introspección, y systemd puede invocarse con ellas en cualquier momento:
--dump-configuration-items
Volca los elementos de configuración de unidad que se entienden. Esto genera una lista concisa pero completa de los elementos de configuración que se entienden en los archivos de definición de unidades.
--dump-bus-properties
Volca las propiedades de bus expuestas. Esto genera una lista concisa pero completa de las propiedades expuestas en D-Bus.
Añadido en la versión 239.
--test
Determina la transacción de inicio inicial (es decir, la lista de trabajos encolados al inicio), la volca y sale, sin ejecutar realmente ninguno de los trabajos determinados. Esta opción es útil solo para depuración. Tenga en cuenta que, durante el inicio normal del administrador de servicios, es posible que se inicien unidades adicionales que no se muestran con esta operación, porque el hardware, los sockets, el bus u otros tipos de activación pueden agregar trabajos adicionales a medida que se ejecuta la transacción. Utilice --system para solicitar la transacción inicial del administrador de servicios del sistema (este es también el valor predeterminado implícito), combine con --user para solicitar la transacción inicial del administrador de servicios por usuario en su lugar.
--system, --user
Cuando se utiliza en conjunto con --test, selecciona si se debe calcular la transacción inicial para la instancia del sistema o para una instancia por usuario. Estas opciones no tienen ningún efecto cuando se invocan sin --test, ya que durante las invocaciones regulares (es decir, no --test), el administrador de servicios detectará automáticamente si debe operar en modo de sistema o por usuario, verificando si el PID en el que se ejecuta es 1 o no. Tenga en cuenta que no se admite arrancar y mantener un sistema con el administrador de servicios que se ejecuta en modo --system pero con un PID distinto de 1.
-h, --help
Imprime un breve texto de ayuda y sale.
--version
Imprime una breve cadena de versión y sale.
Opciones que duplican la configuración de la línea de comandos del kernel
Estas opciones corresponden directamente a las opciones que se enumeran anteriormente en "Línea de comandos del kernel". Ambas formas se pueden utilizar de forma equivalente para el administrador del sistema, pero se recomienda utilizar las formas que se enumeran anteriormente en este contexto, porque tienen el espacio de nombres correcto. Cuando se especifica una opción tanto en la línea de comandos del kernel como como un argumento de línea de comandos normal, esta última tiene prioridad.
Cuando systemd se utiliza como administrador de usuarios, se ignora la línea de comandos del kernel y solo se entienden las opciones que se describen a continuación. Sin embargo, systemd normalmente se inicia en este modo a través del servicio [[email protected](5)], que se comparte entre todos los usuarios. Puede ser más conveniente utilizar archivos de configuración para modificar la configuración (consulte systemd-user.conf, o variables de entorno. Consulte la sección "Entorno" anterior para obtener una discusión sobre cómo se establece el bloque de entorno.
--unit=
Establece la unidad predeterminada que se activará al inicio. Si no se especifica, el valor predeterminado es default.target. Consulte systemd.unit= arriba.
--dump-core
Habilita el volcado de memoria en caso de fallo. Esta opción no tiene efecto cuando se ejecuta como una instancia de usuario. Es el mismo que systemd.dump_core= arriba.
--crash-vt=VT
Cambia a una consola virtual específica (VT) en caso de fallo. Esta opción no tiene efecto cuando se ejecuta como una instancia de usuario. Es el mismo que systemd.crash_chvt= arriba (¡pero con una ortografía diferente!).
Añadido en la versión 227.
--crash-shell
Ejecuta una shell en caso de fallo. Esta opción no tiene efecto cuando se ejecuta como una instancia de usuario. Consulte systemd.crash_shell= arriba.
--crash-action=
Especifica qué hacer cuando el administrador del sistema (PID 1) falla. Esta opción no tiene efecto cuando systemd se ejecuta como una instancia de usuario. Consulte systemd.crash_action= arriba.
Añadido en la versión 256.
--confirm-spawn
Solicita confirmación al generar procesos. Esta opción no tiene efecto cuando se ejecuta como una instancia de usuario. Consulte systemd.confirm_spawn arriba.
--show-status
Muestra información de estado resumida de la unidad en la consola durante el inicio y el apagado. Consulte systemd.show_status arriba.
Añadido en la versión 244.
--log-color
Resalta los mensajes de registro importantes. Consulte systemd.log_color arriba.
Añadido en la versión 244.
--log-level=
Establece el nivel de registro. Consulte systemd.log_level arriba.
--log-location
Incluye la ubicación del código en los mensajes de registro. Consulte systemd.log_location arriba.
Añadido en la versión 244.
--log-target=
Establece el destino del registro. Consulte systemd.log_target arriba.
--log-time=
Prefija los mensajes de la consola con la marca de tiempo. Consulte systemd.log_time arriba.
Añadido en la versión 246.
--machine-id=
Anula el machine-id establecido en el disco duro. Consulte systemd.machine_id= arriba.
Añadido en la versión 229.
--service-watchdogs
Habilita o deshabilita globalmente todos los tiempos de espera del watchdog de los servicios y las acciones de emergencia. Consulte systemd.service_watchdogs arriba.
Añadido en la versión 237.
--default-standard-output=, --default-standard-error=
Establece la salida o la salida de error predeterminadas para todos los servicios y sockets, respectivamente. Consulte systemd.default_standard_output= y systemd.default_standard_error= arriba.
ÉPOCA DEL RELOJ DEL SISTEMA
Cuando systemd se inicia o se reinicia, puede establecer el reloj del sistema a la "época". Este mecanismo se utiliza para garantizar que el reloj del sistema permanezca razonablemente inicializado y aproximadamente monótono entre reinicios, en caso de que no haya un RTC local con batería o no funcione correctamente.
La época es la fecha más antigua por encima de la cual se supone que el tiempo del reloj del sistema está establecido correctamente. Al inicializar, el reloj local se avanza a la época si se estableció en un valor anterior. Como caso especial, si el reloj local está suficientemente en el futuro (por defecto, 15 años, pero esto se puede configurar en tiempo de compilación), se supone que el reloj de hardware está roto y el reloj del sistema se retrocede a la época.
La época se establece en el valor más alto de: la hora de compilación de systemd, la hora de modificación ("mtime") de /usr/lib/clock-epoch y la hora de modificación de /var/lib/systemd/timesync/clock.
ARCHIVOS
/run/systemd/notify
Socket de notificación de estado del daemon. Este es un socket de datagrama AF_UNIX y se utiliza para implementar la lógica de notificación del daemon tal como se implementa en sd_notify(3).
/run/systemd/private
Se utiliza internamente como canal de comunicación entre [systemctl]({filename}../../systemctl)(1) y el proceso systemd. Este es un socket de flujo AF_UNIX. Esta interfaz es privada de systemd y no debe utilizarse en proyectos externos.
/usr/lib/clock-epoch
El tiempo de modificación ("mtime") de este archivo se utiliza para la época del tiempo, consulte la sección anterior.
Añadido en la versión 247.
/var/lib/systemd/timesync/clock
El tiempo de modificación ("mtime") de este archivo se actualiza mediante systemd-timesyncd.service(8). Si está presente, el tiempo de modificación del archivo se utiliza para la época, consulte la sección anterior.
Añadido en la versión 257.
HISTORIAL
systemd 252
Los argumentos de la línea de comandos del kernel systemd.unified_cgroup_hierarchy y systemd.legacy_systemd_cgroup_controller se han marcado como obsoletos. Por favor, cambie a la jerarquía de cgroup unificada.
VER TAMBIÉN
La página de inicio de systemd[9], systemd-system.conf(5), locale.conf(5), systemctl(1), journalctl(1), systemd-notify(1), daemon(7), sd-daemon(3), org.freedesktop.systemd1(5), systemd.unit(5), systemd.special(7), pkg-config(1), kernel-command-line(7), bootup(7), systemd.directives(7), org.freedesktop.systemd1(5)
Para obtener más información sobre los conceptos y las ideas detrás de systemd, consulte el Documento de diseño original[10].
NOTAS
Portabilidad y estabilidad de la interfaz
https://systemd.io/PORTABILITY_AND_STABILITY/
Interfaz de contenedor
https://systemd.io/CONTAINER_INTERFACE
Interfaz initrd
https://systemd.io/INITRD_INTERFACE/
Control Groups v2
https://docs.kernel.org/admin-guide/cgroup-v2.html
Especificación del directorio base XDG
https://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html
Se recomienda que otras herramientas establezcan y verifiquen $SUDO_UID según corresponda, tratándolo como una interfaz común.
Variables de entorno conocidas
https://systemd.io/ENVIRONMENT
Credenciales de sistema y servicio
https://systemd.io/CREDENTIALS
Página de inicio de systemd
https://systemd.io/
Documento de diseño original
https://0pointer.de/blog/projects/systemd.html