systemd/User (Español)

From ArchWiki
< Systemd
Revision as of 20:31, 25 September 2013 by Pedro (Talk | contribs) (Véase también)

Jump to: navigation, search

Template:Article summary start Template:Article summary text Template:Article summary heading Template:Article summary wiki Template:Article summary end

systemd ofrece a los usuarios la capacidad de ejecutar una instancia de systemd para gestionar la sesión y los servicios. Esto permite a los usuarios iniciar, detener, habilitar y deshabilitar las unidades que se encuentren dentro de ciertas carpetas cuando systemd se ejecuta por el usuario. Esto es conveniente para los demonios y otros servicios que normalmente se ejecutan como un usuario diferente a root o un usuario especial, como por ejemplo mpd

Configuración desde systemd 206

Nota: Las sesiones de usuario están en desarrollo, por lo que faltan algunas características, que aún no están apoyadas por los desarrolladores. Véase [[1]] y [[2]] para obtener más detalles sobre el estado actual del asunto.

Desde la versión 206, el mecanismo para instancias de usuario de systemd ha cambiado. Ahora el módulo pam_systemd.so lanza una instancia de usuario, por defecto, en el primer inicio de sesión de un usuario, iniciando user@.service. En el estado actual, existen algunas diferencias con respecto a versiones anteriores de systemd, que hay que tener en cuenta:

  • La instancia systemd --user se ejecuta fuera de cualquier sesión de usuario. Esto está bien para correr, por ejemplo mpd, pero puede ser molesto si uno trata de iniciar un gestor de ventanas desde la instancia de usuario de systemd. Entonces polkit evita montar usb, reinicar, etc., como un usuario normal, porque el gestor de ventanas se ha ejecutado fuera de la sesión activa.
  • Las unidades en la instancia de usuario no heredan cualquier entorno, por lo que se debe fijar manualmente.
  • user-session@.service de user-session-unitsAUR está ahora obsoleto.

Pasos para utilizar las unidades de instancia de usuario:

1. Asegúrese de que la instancia de usuario de systemd se inicia correctamente. Puede comprobar esto con:
systemctl --user status
Desde systemd 206 debe haber una instancia de usuario ejecutando systemd por defecto, que se inicia en el módulo pam pam_systemd.so para la primera sesión de un usuario.
Nota: Desde la version 207, systemd utiliza un servicio PAM diferente para user@.service, e incluye una configuración PAM por defecto incorrecta. Soluciónelo con: # sed -i s/system-auth/system-login/g /etc/pam.d/systemd-user (o sustituya todas las apariciones de system-auth en ese archivo con system-login).

2. Agregue las variables de entorno que necesita, en un párrafo en el archivo de configuración para user@.service. Al menos, debe contener lo siguiente:

/etc/systemd/system/user@.service.d/environment.conf
[Service]
Environment=DISPLAY=:0
Environment=XDG_RUNTIME_DIR=/run/user/%I
Environment=SHELL=%s

3. Ponga todas sus unidades de usuario en $HOME/.config/systemd/user. Cuando inicie la instancia de usuario, lance el target predeterminado $HOME/.config/systemd/user/default.target. Después de eso, se pueden manejar las unidades de usuario con systemctl --user.

Configuración

startx

Nota: Este paso no es necesario si vamos a utilizar autologin.

Lo primero que debemos hacer es ajustar systemd-logind para gestionar la propia sesión. Si systemd se ejecuta como el demonio init del sistema, entonces esta operación ya está sucediendo.

A continuación, se debe iniciar systemd colocando en el archivo ~/.xinitrc lo siguiente:

/usr/lib/systemd/systemd --user
Si no estamos lanzando el gestor de ventanas a través de /usr/lib/systemd/systemd --user, entonces será necesario insertar
/usr/lib/systemd/systemd --user &
en el archivo ~/.xinitrc, de modo que lance systemd como cualquier otra aplicación, antes de ejecutar el gestor de ventanas.

Después de iniciar X, se puede comprobar si la sesión está siendo gestionada por systemd-logind con la siguiente orden:

$ loginctl --no-pager show-session $XDG_SESSION_ID | grep Active

Si la salida de la orden es Active=yes, entonces estamos usando systemd-logind para gestionar la sesión. Debemos eliminar cualquier referencia a ck-launch-session o dbus-launch del propio ~/.xinitrc, en cuanto que son órdenes innecesarias.

Gestores de pantalla

Todos los gestores de pantalla principales están usando systemd-logind de forma predeterminada, por lo que la orden loginctl del apartado anterior debería funcionar como se indica. El usuario solo tiene que añadir systemd --user como si se tratara de un programa a iniciar en el propio entorno de escritorio.

GNOME 3 (utilizando GDM)

Para los usuarios que desean tener GDM/GNOME 3 iniciando la sesión /usr/lib/systemd/systemd --user automáticamente al conectarse, solo hay que crear una sesión de login especial:

/usr/share/xsessions/gnome-systemd.desktop
[Desktop Entry]
Type=Application
Name=systemd
Comment=Runs 'systemd' as a user instance.
Exec=/usr/lib/systemd/systemd --user

Asegúrese de elegir la sesión systemd entre las opciones de la pantalla de acceso de GDM.

Nota: Lo anterior solo ha sido probado con una configuración pura de GDM y GNOME 3. En caso de configuraciones alternativas, su experiencia puede variar. Este método no requiere la instalación de los scripts user-session de systemd.

Utilizar /usr/lib/systemd/systemd --user para gestionar la propia sesión

Systemd tiene muchas características sorprendentes, una de ellas es la capacidad de hacer un seguimiento de los programas utilizando cgroups (ejecutando systemctl status). Aunque esto es realmente útil para un sistema de init en cuyo proceso hay un pid 1, también es muy útil para los usuarios que quieran utilizar esta función para iniciar automáticamente los programas de los mismos, haciendo un seguimiento simultáneamente del contenido de cada cgrupo.

Todas las unidades de usuario de systemd residirán en $HOME/.config/systemd/user. Estas unidades tienen prioridad sobre otras unidades en residentes en otros directorios de unidades de systemd.

Necesitamos dos paquetes para conseguir este trabajo, por un lado, el disponible actualmente desde AUR: systemd-xorg-launch-helper-gitAUR y, opcionalmente, por otro lado, systemd-user-session-units-gitAUR si desea trabajar con autologin.

Lo siguiente será crear los targets («objetivos»). Configuraremos dos: uno para el gestor de ventanas, y otro como un target por defecto. El target del gestor de ventanas debe ser similar a lo siguiente:

$HOME/.config/systemd/user/wm.target
[Unit]
Description=Window manager target
Wants=xorg.target
Wants=mystuff.target
Requires=dbus.socket
AllowIsolate=true

[Install]
Alias=default.target

Este será el target de su interfaz gráfica.

Crearemos un segundo target llamado mystuff.target. Valdrá para todos los servicios, pero debe contener el gestor de ventanas elegido en la línea WantedBy, bajo [Install], señalando a esta unidad.

$HOME/.config/systemd/user/mystuff.target
[Unit]
Description=Xinitrc Stuff
Wants=wm.target

[Install]
Alias=default.target

Crearemos un enlace simbólico de nombre default.target. Cuando se inicie /usr/lib/systemd/systemd --user, dicho target vendrá iniciado también.

Por último, nececitamos escribir varios archivos de servicios correspondientes a los servicios que deben comenzar. Para ello, asociaremos un servicio al gestor de ventanas.

$HOME/.config/systemd/user/YOUR_WM.service
[Unit]
Description=your window manager service
Before=mystuff.target
After=xorg.target
Requires=xorg.target

[Service]
#Environment=PATH=uncomment:to:override:your:PATH
ExecStart=/full/path/to/wm/executable
Restart=always
RestartSec=10
 
[Install]
WantedBy=wm.target
Nota: La sección [Install] incluye el valor 'WantedBy'. Cuando usamos systemctl --user enable se asocia a este como $HOME/.config/systemd/user/wm.target.wants/YOUR_WM.service, lo que le permite arrancarlo al iniciar sesión. Se recomienda activar este servicio, en lugar de unirlo de forma manual.

Se puede poblar el directorio de unidades de usuario con una gran cantidad de servicios, incluyendo, a modo de ejemplo, algunos como mpd, gpg-agent, offlineimap, parcellite, pulse, tmux, urxvtd, xbindkeys y xmodmap.

Para salir de su sesión, utilice systemctl --user exit.

Inicio de sesión automático

Si se quiere iniciar sesión automáticamente al arrancar con systemd, es posible utilizar la unidad correspondiente proporcionada por el paquete user-session-units. Considere la posibilidad de activar una pantalla locker para evitar que cualquier pueda valerse de la sesión recién iniciada. Añada esta línea a /etc/pam.d/login y a /etc/pam.d/system-auth:

session    required    pam_systemd.so

Debido a que user-session@.service viene iniciado en tty1, será necesario añadir Conflicts=getty@tty1.service al archivo de servicio en cuestión, si no existe ya. Como alternativa, puede hacer que se ejecute en tty7 en su lugar, modificando TTYPath en consecuencia, así como la línea ExecStart en xorg.service (cp /usr/lib/systemd/user/xorg.service /etc/systemd/user/ y haciendo las modificaciones allí).

Una vez hecho esto, ejecute systemctl --user enable YOUR_WM.service

Nota: Hay que prestar atención a la tty de modo que la sesión de systemd esté marcada como activa. Systemd establece una sesión como inactiva cuando la tty activa es diferente de aquella en la cual se ha inicio sesión. Esto significa que el servidor X se debe ejecutar en la misma tty especificada en user-session@.service. Si la tty en TTYPath no coincide con el xorg lanzado, la sesión de systemd estará inactiva desde el punto de vista de las aplicaciones de X, y no será capaz de montar las unidades USB, por ejemplo.

Una de las cosas más importantes es añadir al propio archivo de servicio el uso de Before= y After= en la sección [Unit]. Esto permitirá determinar el orden de inicio de los servicios. Pongamos por caso que queremos disponer de una aplicación gráfica que se inicie al arranque, para ello será necesario añadir After=xorg.target a la propia sección unit. Otro caso, como por ejemplo iniciar ncmpcpp, el cual requiere mpd para funcionar, será necesario añadir After=mpd.service a la sección unit de ncmpcpp. El tiempo y la experiencia arrojarán luz sobre cómo gestionar el orden de inicio de las aplicaciones, o bien consultando la página de man de systemd. Comenzar con systemd.unit(5) sería una buena idea.

Otros casos de uso

Multiplexor de terminal persistente

Es posible que quiera utilizar la propia sesión de usuario para iniciar un multiplexor de terminal como GNU Screen o Tmux, como fondo de pantalla para conectarse, en lugar de iniciar la sesión de un gestor de ventanas. Separar el login del login gráfico es probablemente útil para los usuarios que efectuan el arranque en una TTY, en lugar de utilizar un gestor de pantallas (en cuyo caso es posible insertar todos los programas de arranque en el target myStuff.target).

Para crear este tipo de sesión de usuario, proceda como se indica anteriormente, pero en lugar de crear wm.target, cree multiplexer.target:

[Unit]
Description=Terminal multiplexer
Documentation=info:screen man:screen(1) man:tmux(1)
After=cruft.target
Wants=cruft.target

[Install]
Alias=default.target

El target cruft.target, similar a myStuff.target, debería ocuparse de todos aquellos programas que consideremos que deberían empezar antes que tmux o screen (o que queremos iniciar al arranque independientemente del tiempo), como por ejemplo una sesión del demonio GnuPG.

Para todo esto, será necesario crear un servicio para la propia sesión del multiplexor. He aquí un servicio de muestra que utiliza tmux como ejemplo y provee una sesión gpg-agent que escribe la propia información en /tmp/gpg-agent-info. Esta sesión de muestra, al tiempo que inicia X, también es capaz de hacer correr programas gráficos, desde el momento en que la variable DISPLAY es ajustada.

[Unit]
Description=tmux: A terminal multiplixer Documentation=man:tmux(1)
After=gpg-agent.service
Wants=gpg-agent.service

[Service]
Type=forking
ExecStart=/usr/bin/tmux start
ExecStop=/usr/bin/tmux kill-server
Environment=DISPLAY=:0
EnvironmentFile=/tmp/gpg-agent-info

[Install]
WantedBy=multiplexer.target

Una vez hecho esto, systemctl --user enable, tmux.service, multiplexer.target y cualquier otro programa creado, serán ejecutados por cruft.target. Active user-session@.service como se describió antes, pero asegúrese de retirar el servicio Conflicts=getty@tty1.service de user-session@.service, puesto que la sesión de usuario no se hará cargo de una TTY. ¡Enhorabuena! ¡Ahora tiene un multiplexor de terminal en funcionamiento y otros programas útiles listos para iniciar en el arranque!

Iniciar X

Habrá podido advertir que, desde el multiplexor de terminal es ahora default.target. X no se iniciará automáticamente en el arranque. Para iniciar X, proceda como antes, pero no active o enlace manualmente wm.target a default.target. En su lugar, asumiendo que arranca desde un terminal, vamos a utilizar simplemente una solución temporal y enmascarar /usr/bin/startx con un alias de shell:

alias startx='systemctl --user start wm.target'

Servicios de ususario

Ahora los usuarios pueden interactuar con las unidades ubicadas en los carpetas relacionadas más abajo, tal como lo harían con los servicios del sistema (carpetas ordenadas por prioridad ascendente):

  • /usr/lib/systemd/user/
  • /etc/systemd/user/
  • ~/.config/systemd/user/

Para el control de la instancia de systemd, se debe utilizar la orden systemctl --user.

Unidades instaladas por los paquetes

Una unidad proveída por un paquete está destinada a ser ejecutada por una instancia de usuario de systemd que instalará la unidad en /usr/lib/systemd/user/. La administración del sistema puede modificar la unidad copiándola a /etc/systemd/user/. Un usuario puede modificar la unidad copiándola a ~/.config/systemd/user/.

Ejemplo

El siguiente es un ejemplo de una versión de mpd.service realizada por el usuario:

[Unit]
Description=Music Player Daemon

[Service]
ExecStart=/usr/bin/mpd --no-daemon

[Install]
WantedBy=default.target

Ejemplo con variables

El siguiente es un ejemplo de una versión de usuario de sickbeard.service, que tiene en cuenta los directorios home como variable, donde SickBeard puede encontrar ciertos archivos:

[Unit]
Description=SickBeard Daemon

[Service]
ExecStart=/usr/bin/env python2 /opt/sickbeard/SickBeard.py --config %h/.sickbeard/config.ini --datadir %h/.sickbeard

[Install]
WantedBy=default.target

Como se detalla en man systemd.unit, la variable %h es reemplazada por la carpeta home del usuario que ejecuta el servicio. Hay otras variables en las manpages de systemd que puede tenerlas en cuenta.

Nota acerca de las aplicaciones X

La mayoría de las aplicaciones X necesita una variable DISPLAY para ser iniciada (si el propio servicio no se ha iniciado, con lo cual es la primera cosa a controlar), así que hay que asegurarse de incluir lo siguiente:

$HOME/.config/systemd/user/parcellite.service
[Unit]
Description=Parcellite clipboard manager

[Service]
ExecStart=/usr/bin/parcellite
Environment=DISPLAY=:0 # <= !

[Install]
WantedBy=mystuff.target

Una manera más simple, si se utiliza user-session-unitsAUR, es definirlo en user-session@yourloginname.service que lo heredará. Añada Environment=DISPLAY=:0 a la sección [Service]. Otra variable de entorno útil para establecer aquí es SHELL.

Sin embargo, será preferible no insertar directamente el valor de la variable DISPLAY en el servicio (especialmente si se ejecuta más de una respecto a la pantalla):

$HOME/.config/systemd/user/x-app-template@.service
[Unit]
Description=Your amazing and original description

[Service]
ExecStart=/full/path/to/the/app
Environment=DISPLAY=%i # <= !

[Install]
WantedBy=mystuff.target

A continuación, se puede ejecutar con:

systemctl --user {start|enable} x-app@your-desired-display.service # <= :0 in most cases

Algunas aplicaciones X pueden no ponerse en marcha porque el socket de la pantalla aún no está disponible. Esto se puede solucionarlo mediante la adición de algo así:

$HOME/.config/systemd/user/x-app-template@.service
[Unit]
After=xorg.target
Requires=xorg.target

...

a sus unidades (el target xorg.target es parte del paquete xorg-launch-helperAUR).

Véase también