Difference between revisions of "Systemd/User (Español)"

From ArchWiki
Jump to: navigation, search
(Configuración desde systemd 206)
m
(15 intermediate revisions by one other user not shown)
Line 4: Line 4:
 
[[en:Systemd/User]]
 
[[en:Systemd/User]]
 
[[it:Systemd/User]]
 
[[it:Systemd/User]]
{{Article summary start|Sumario}}
+
[[ja:Systemd/User]]
{{Article summary text|Información sobre cómo configurar las sesiones de usuario de [[systemd (Español)|systemd]]}}
+
{{Related articles start (Español)}}
{{Article summary heading|Relacionado}}
+
{{Related|systemd (Español)}}
{{Article summary wiki|systemd (Español)}}
+
{{Related|Automatic login to virtual console (Español)}}
{{Article summary end}}
+
{{Related|Start X at Login (Español)}}
 +
{{Related articles end}}
  
 
[[systemd (Español)|systemd]] ofrece a los usuarios la capacidad de ejecutar una instancia de [[systemd (Español)|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]]
 
[[systemd (Español)|systemd]] ofrece a los usuarios la capacidad de ejecutar una instancia de [[systemd (Español)|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]]
Line 21: Line 22:
 
Pasos para utilizar las unidades de instancia de usuario:
 
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: {{bc|systemctl --user status}} Desde systemd 206 debe haber una instancia de usuario ejecutando systemd por defecto, que se inicia en el módulo pam {{ic|pam_systemd.so}} para la primera sesión de un usuario.
 
1. Asegúrese de que la instancia de usuario de systemd se inicia correctamente. Puede comprobar esto con: {{bc|systemctl --user status}} Desde systemd 206 debe haber una instancia de usuario ejecutando systemd por defecto, que se inicia en el módulo pam {{ic|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.
+
{{Nota|system-login necesita para comenzar de pam_systemd: este debe contener {{ic|-session  optional  pam_systemd.so}}; compruebe si existe el archivo ''.pacnew''.}}
Soluciónelo con: {{ic|# sed -i s/system-auth/system-login/g /etc/pam.d/systemd-user}} (o sustituya todas las apariciones de {{ic|system-auth}} en ese archivo con {{ic|system-login}}).}}
+
 
2. Agregue las variables de entorno que necesita, en un párrafo en el archivo de configuración para {{ic|user@.service}}. Al menos, debe contener lo siguiente:
 
2. Agregue las variables de entorno que necesita, en un párrafo en el archivo de configuración para {{ic|user@.service}}. Al menos, debe contener lo siguiente:
 
{{hc|/etc/systemd/system/user@.service.d/environment.conf|
 
{{hc|/etc/systemd/system/user@.service.d/environment.conf|
 
[Service]
 
[Service]
 
Environment=DISPLAY=:0
 
Environment=DISPLAY=:0
Environment=XDG_RUNTIME_DIR=/run/user/%I
 
Environment=SHELL=%s
 
 
}}
 
}}
3. Ponga todas sus unidades de usuario en {{ic|$HOME/.config/systemd/user}}. Cuando inicie la instancia de usuario, lance el target predeterminado {{ic|$HOME/.config/systemd/user/default.target}}.  Después de eso, se pueden manejar las unidades de usuario con {{ic|systemctl --user}}.
+
3. Ponga todas sus unidades de usuario en {{ic|~/.config/systemd/user}}. Cuando inicie la instancia de usuario, lance el target predeterminado {{ic|~/.config/systemd/user/default.target}}.  Después de eso, se pueden manejar las unidades de usuario con {{ic|systemctl --user}}.
  
== Configuración ==
+
=== D-Bus ===
  
=== startx ===
+
Para utilizar [[D-Bus (Español)|dbus]] en unidades de usuario, cree los siguientes archivos:
  
{{Nota|Este paso no es necesario si vamos a utilizar autologin.}}
+
{{hc|/etc/systemd/user/dbus.socket|<nowiki>
 +
[Unit]
 +
Description=D-Bus Message Bus Socket
 +
Before=sockets.target
  
Lo primero que debemos hacer es ajustar systemd-logind para gestionar la propia sesión. Si [[Systemd (Español)|systemd]] se ejecuta como el demonio init del sistema, entonces esta operación ya está sucediendo.
+
[Socket]
 +
ListenStream=/run/user/%U/dbus/user_bus_socket
  
A continuación, se debe iniciar systemd colocando en el archivo  {{ic|~/.xinitrc}} lo siguiente:
+
[Install]
{{bc|systemd --user}}
+
WantedBy=default.target
Si no estamos lanzando el gestor de ventanas a través de systemd --user, entonces será necesario insertar {{bc|systemd --user &}} en el archivo {{ic|~/.xinitrc}}, de modo que lance systemd como cualquier otra aplicación, antes de ejecutar el gestor de ventanas.
+
</nowiki>}}
  
Después de iniciar X, se puede comprobar si la sesión está siendo gestionada por systemd-logind con la siguiente orden:
+
{{hc|/etc/systemd/user/dbus.service|<nowiki>
 +
[Unit]
 +
Description=D-Bus Message Bus
 +
Requires=dbus.socket
  
{{bc|<nowiki>
+
[Service]
$ loginctl --no-pager show-session $XDG_SESSION_ID | grep Active
+
ExecStart=/usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation
 +
ExecReload=/usr/bin/dbus-send --print-reply --session --type=method_call --dest=org.freedesktop.DBus / org.freedesktop.DBus.ReloadConfig
 
</nowiki>}}
 
</nowiki>}}
  
Si la salida de la orden es {{ic|1=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 {{ic|~/.xinitrc}}, en cuanto que son órdenes innecesarias.
+
Active el socket ejecutando:
  
=== Gestores de pantalla ===
+
# systemctl --global enable dbus.socket
Todos los gestores de pantalla principales están usando systemd-logind de forma predeterminada, por lo que la orden {{ic | loginctl}} del apartado anterior debería funcionar como se indica. El usuario solo tiene que añadir {{ic|systemd --user}} como si se tratara de un programa a iniciar en el propio entorno de escritorio.
+
  
==== GNOME 3 (utilizando GDM) ====
+
La unidad {{ic|user@.service}} que lanza la instancia systemd del usuario, exporta, por defecto, la siguiente ruta de bus:
Para los usuarios que desean tener GDM/GNOME 3 iniciando la sesión {{ic|systemd --user}} automáticamente al conectarse, solo hay que crear una sesión de login especial:
+
 
{{hc|/usr/share/xsessions/gnome-systemd.desktop|<nowiki>
+
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/%I/dbus/user_bus_socket
[Desktop Entry]
+
 
Type=Application
+
que se propaga para los servicios que se ejecutan en esta instancia. Sin embargo, se ha sugerido que cada sesión de usuario debe tener su propia instancia de demonio dbus (lo que significa que debe usar, por ejemplo, el esqueleto [[xinitrc (Español)|xinitrc]], que inicia el demonio dbus para la sesión de Xorg ). Hay un debate en curso sobre este tema en la [http://lists.freedesktop.org/archives/systemd-devel/2013-March/009422.html lista de correo de systemd]. Como la decisión final no se ha tomado todavía, no existe una solución oficial.
Name=systemd
+
 
Comment=Runs 'systemd' as a user instance.
+
=== Inicio de sesión automático en Xorg sin gestor de pantallas ===
Exec=/usr/lib/systemd/systemd --user
+
 
 +
Se necesita tener [[#D-Bus]] correctamente configurado y {{AUR|xlogin-git}} instalado.
 +
 
 +
Configure [[xinitrc (Español)|xinitrc]] desde el esqueleto, para que le suministre los archivos en {{ic|/etc/X11/xinit/xinitrc.d/}}. El funcionamiento de {{ic|~/.xinitrc}} no debe retornar a sí mismo, por lo que o bien tiene {{ic|wait}} como última orden, o añada {{ic|exec}} a la última orden que es llamada y que no debe consistir en retornar (por ejemplo, llamar al gestor de ventanas).
 +
 
 +
La sesión utilizará su propio demonio dbus, pero varias utilidades systemd necesitarán la instancia {{ic|dbus.service}}. Una posible solución a esto es crear alias para estas órdenes:
 +
 
 +
{{hc|~/.bashrc|<nowiki>
 +
for sd_cmd in systemctl systemd-analyze systemd-run; do
 +
    alias $sd_cmd='DBUS_SESSION_BUS_ADDRESS="unix:path=$XDG_RUNTIME_DIR/dbus/user_bus_socket" '$sd_cmd
 +
done
 
</nowiki>}}
 
</nowiki>}}
  
Asegúrese de elegir la sesión {{ic|systemd}} entre las opciones de la pantalla de acceso de GDM.
+
Por último, active ('''como root''') el servicio ''xlogin'' para iniciar automáticamente sesión al arrancar:
{{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.}}
+
 
 +
# systemctl enable xlogin@''nombredeusuario''
 +
 
 +
La sesión de usuario se desarrolla enteramente dentro de un espacio systemd y todo en la sesión de usuario debería funcionar bien.
 +
 
 +
=== Puesta en marcha automática de instancias de usuario de systemd ===
 +
 
 +
La instancia de usuario de systemd es, por defecto, ejecutada después del primer inicio de sesión de un usuario, pero, a veces, puede ser útil empezar aquella después del arranque. Lingering se utiliza para generar la instancia de usuario systemd en el arranque y que siga funcionando después del cierre de sesión.
 +
 
 +
{{Advertencia|Los servicios de systemd '''no''' son sesiones, se ejecutan fuera de ''logind''. No utilice lingering para permitir el inicio de sesión automática, ya que [[General Troubleshooting#Session permissions|rompe la sesión]].}}
 +
 
 +
Utilice la siguiente orden para activar lingering para el usuario específico:
 +
 
 +
# loginctl enable-linger ''nombredeusuario''
 +
 
 +
== Configuración ==
 +
{{Out of date|After systemd 206, systemd --user mechanism has changed. (See [[https://bugs.freedesktop.org/show_bug.cgi?id=67471]], [[http://lists.freedesktop.org/archives/systemd-devel/2013-July/012392.html]], [[http://lists.freedesktop.org/archives/systemd-devel/2013-August/012517.html]]) }}
  
=== Utilizar systemd --user para gestionar la propia sesión ===
+
=== 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 {{ic|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.
 
Systemd tiene muchas características sorprendentes, una de ellas es la capacidad de hacer un seguimiento de los programas utilizando cgroups (ejecutando {{ic|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.
Line 74: Line 105:
 
Todas las unidades de usuario de systemd residirán en {{ic|$HOME/.config/systemd/user}}. Estas unidades tienen prioridad sobre otras unidades en residentes en otros directorios de unidades de systemd.
 
Todas las unidades de usuario de systemd residirán en {{ic|$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 [[Arch User Repository (Español)|AUR]]: {{AUR|xorg-launch-helper}} y, opcionalmente, por otro lado, {{AUR|user-session-units}} si desea trabajar con autologin.  
+
Necesitamos dos paquetes para conseguir este trabajo, por un lado, el disponible actualmente desde [[Arch User Repository (Español)|AUR]]: {{AUR|systemd-xorg-launch-helper-git}} y, opcionalmente, por otro lado, {{AUR|systemd-user-session-units-git}} si desea trabajar con autologin.  
  
Lo siguiente será crear los objetivos (''targets''). 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:
+
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:
  
 
{{hc|$HOME/.config/systemd/user/wm.target|<nowiki>
 
{{hc|$HOME/.config/systemd/user/wm.target|<nowiki>
Line 82: Line 113:
 
Description=Window manager target
 
Description=Window manager target
 
Wants=xorg.target
 
Wants=xorg.target
Wants=myStuff.target
+
Wants=mystuff.target
 
Requires=dbus.socket
 
Requires=dbus.socket
 
AllowIsolate=true
 
AllowIsolate=true
Line 102: Line 133:
 
</nowiki>}}
 
</nowiki>}}
  
Crearemos un enlace simbólico de nombre {{ic|default.target}}. Cuando se inicie {{ic|systemd --user}}, dicho target vendrá iniciado también.  
+
Crearemos un enlace simbólico de nombre {{ic|default.target}}. Cuando se inicie {{ic|/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.
 
Por último, nececitamos escribir varios archivos de servicios correspondientes a los servicios que deben comenzar. Para ello, asociaremos un servicio al gestor de ventanas.
Line 123: Line 154:
 
</nowiki>}}
 
</nowiki>}}
  
{{Nota|La sección {{ic|[Install]}} incluye el valor 'WantedBy'. Cuando usamos {{ic|systemctl --user enable}} se asocia a este como {{ic|$HOME/.config/systemd/user/wm.target.wants/i3.service}}, lo que le permite arrancarlo al iniciar sesión. Se recomienda activar este servicio, en lugar de unirlo de forma manual.}}
+
{{Nota|La sección {{ic|[Install]}} incluye el valor 'WantedBy'. Cuando usamos {{ic|systemctl --user enable}} se asocia a este como {{ic|$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'''.
 
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 {{ic|systemctl --user exit}}.
  
 
===Inicio de sesión automático===
 
===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.  
 
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 {{ic|/etc/pam.d/login}} y a {{ic|/etc/pam.d/system-auth}}:
 +
{{bc|session    required    pam_systemd.so}}
  
Si se ha instalado el paquete user-session-units, será necesario copiar {{ic|user-session@.service}} al directorio {{ic|/etc/systemd/system}} y editar el servicio {{ic|user-session@.service}} (no el {{ic|user-session@yourloginname.service}}) y modificar estas líneas:
+
Debido a que {{ic|user-session@.service}} viene iniciado en tty1, será necesario añadir {{ic|1=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 {{ic|TTYPath}} en consecuencia, así como la línea {{ic|ExecStart}} en {{ic|xorg.service}} ({{ic|cp /usr/lib/systemd/user/xorg.service /etc/systemd/user/}} y haciendo las modificaciones allí).
  
{{bc|1=Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/%I/dbus/user_bus_socket}}
+
Una vez hecho esto, ejecute {{ic|systemctl --user enable}} {{ic|YOUR_WM.service}}
  
por estas:
+
{{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 {{ic|user-session@.service}}. Si la tty en {{ic|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.}}
 
+
{{bc|1=Environment=DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/%U/dbus/user_bus_socket}}
+
 
+
{{Nota|Observe la diferencia entre {{ic|%I}} que es sustituido por {{ic|%U}}}}
+
 
+
También se modificará la sección install:
+
 
+
{{bc|1=
+
[Install]
+
WantedBy=graphical.target
+
}}
+
 
+
o, si no se tiene un gestor de inicio de sesión:
+
 
+
{{bc|1=
+
[Install]
+
WantedBy=getty.target
+
}}
+
 
+
Será necesario parchear systemd para utilizar esta funcionalidad, ya sea usando '''systemd-git''' desde [http://cgit.freedesktop.org/systemd/systemd/commit/?id=067d851d30386c553e3a84f59d81d003ff638b91 commit 067d851d] o parchearlo directamente utilizando [[Arch Build System (Español)|ABS]]. La modificación debería ser incluida en systemd a partir de la versión 197.
+
 
+
Añada esta línea a {{ic|/etc/pam.d/login}} y {{ic|/etc/pam.d/system-auth}}:
+
 
+
{{bc|session   required    pam_systemd.so}}
+
 
+
Desde el momento en que {{ic|user-session@.service}} viene iniciado sobre la tty1, será necesario añadir {{ic|1=Conflicts=getty@tty1.service}} al archivo de servicio en cuestión.
+
  
 
Una de las cosas más importantes es añadir al propio archivo de servicio el uso de {{ic|1=Before=}} y {{ic|1=After=}} en la sección {{ic|[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 {{ic|1=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 {{ic|1=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 [http://www.freedesktop.org/software/systemd/man/systemd.unit.html systemd.unit(5)] sería una buena idea.
 
Una de las cosas más importantes es añadir al propio archivo de servicio el uso de {{ic|1=Before=}} y {{ic|1=After=}} en la sección {{ic|[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 {{ic|1=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 {{ic|1=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 [http://www.freedesktop.org/software/systemd/man/systemd.unit.html systemd.unit(5)] sería una buena idea.
  
=== Otros casos ===
+
=== Otros casos de uso===
 
==== Multiplexor de terminal persistente ====
 
==== Multiplexor de terminal persistente ====
  
Line 212: Line 221:
 
{{bc|1=alias startx='systemctl --user start wm.target'}}
 
{{bc|1=alias startx='systemctl --user start wm.target'}}
  
== Servicios del ususario ==
+
== 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):
 
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):
 
* {{ic|/usr/lib/systemd/user/}}
 
* {{ic|/usr/lib/systemd/user/}}
Line 243: Line 252:
  
 
Como se detalla en {{ic|man systemd.unit}}, la variable {{ic|%h}} es reemplazada por la carpeta home del usuario que ejecuta el servicio. Hay otras variables en las manpages de [[systemd (Español)|systemd]] que puede tenerlas en cuenta.
 
Como se detalla en {{ic|man systemd.unit}}, la variable {{ic|%h}} es reemplazada por la carpeta home del usuario que ejecuta el servicio. Hay otras variables en las manpages de [[systemd (Español)|systemd]] que puede tenerlas en cuenta.
 +
 +
=== Nota acerca de las aplicaciones X ===
 +
 +
La mayoría de las aplicaciones X necesita una variable {{ic|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:
 +
 +
{{hc|$HOME/.config/systemd/user/parcellite.service|<nowiki>
 +
[Unit]
 +
Description=Parcellite clipboard manager
 +
 +
[Service]
 +
ExecStart=/usr/bin/parcellite
 +
Environment=DISPLAY=:0 # <= !
 +
 +
[Install]
 +
WantedBy=mystuff.target
 +
</nowiki>}}
 +
 +
Una manera más simple, si se utiliza {{AUR|user-session-units}}, es definirlo en {{ic|user-session@yourloginname.service}} que lo heredará. Añada {{ic|1=Environment=DISPLAY=:0}} a la sección {{ic|[Service]}}. Otra variable de entorno útil para establecer aquí es {{ic|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):
 +
 +
{{hc|$HOME/.config/systemd/user/x-app-template@.service|<nowiki>
 +
[Unit]
 +
Description=Your amazing and original description
 +
 +
[Service]
 +
ExecStart=/full/path/to/the/app
 +
Environment=DISPLAY=%i # <= !
 +
 +
[Install]
 +
WantedBy=mystuff.target
 +
</nowiki>}}
 +
 +
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í:
 +
 +
{{hc|$HOME/.config/systemd/user/x-app-template@.service|<nowiki>
 +
[Unit]
 +
After=xorg.target
 +
Requires=xorg.target
 +
 +
...
 +
</nowiki>}}
 +
 +
a sus unidades (el target {{ic|xorg.target}} es parte del paquete {{AUR|xorg-launch-helper}}).
  
 
== Véase también ==
 
== Véase también ==
* [http://blog.gtmanfred.com/?p=26 gtmanfred's guide - the original guide]
 
 
* [https://bitbucket.org/KaiSforza/systemd-user-units/wiki/Home KaiSforza's bitbucket wiki]
 
* [https://bitbucket.org/KaiSforza/systemd-user-units/wiki/Home KaiSforza's bitbucket wiki]
 +
* [https://github.com/zoqaeski/systemd-user-units Zoqaeski's units on Github]
 
* [https://github.com/grawity/systemd-user-units Collection of useful systemd user units]
 
* [https://github.com/grawity/systemd-user-units Collection of useful systemd user units]
 
* [https://bitbucket.org/KaiSforza/systemd-user-units More systemd user units]
 
* [https://bitbucket.org/KaiSforza/systemd-user-units More systemd user units]
 +
* [https://bbs.archlinux.org/viewtopic.php?id=167115 Forum thread about changes in systemd 206 user instances]

Revision as of 08:09, 12 February 2014

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: system-login necesita para comenzar de pam_systemd: este debe contener -session optional pam_systemd.so; compruebe si existe el archivo .pacnew.

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

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

D-Bus

Para utilizar dbus en unidades de usuario, cree los siguientes archivos:

/etc/systemd/user/dbus.socket
[Unit]
Description=D-Bus Message Bus Socket
Before=sockets.target

[Socket]
ListenStream=/run/user/%U/dbus/user_bus_socket

[Install]
WantedBy=default.target
/etc/systemd/user/dbus.service
[Unit]
Description=D-Bus Message Bus
Requires=dbus.socket

[Service]
ExecStart=/usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation
ExecReload=/usr/bin/dbus-send --print-reply --session --type=method_call --dest=org.freedesktop.DBus / org.freedesktop.DBus.ReloadConfig

Active el socket ejecutando:

# systemctl --global enable dbus.socket

La unidad user@.service que lanza la instancia systemd del usuario, exporta, por defecto, la siguiente ruta de bus:

DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/%I/dbus/user_bus_socket

que se propaga para los servicios que se ejecutan en esta instancia. Sin embargo, se ha sugerido que cada sesión de usuario debe tener su propia instancia de demonio dbus (lo que significa que debe usar, por ejemplo, el esqueleto xinitrc, que inicia el demonio dbus para la sesión de Xorg ). Hay un debate en curso sobre este tema en la lista de correo de systemd. Como la decisión final no se ha tomado todavía, no existe una solución oficial.

Inicio de sesión automático en Xorg sin gestor de pantallas

Se necesita tener #D-Bus correctamente configurado y xlogin-gitAUR instalado.

Configure xinitrc desde el esqueleto, para que le suministre los archivos en /etc/X11/xinit/xinitrc.d/. El funcionamiento de ~/.xinitrc no debe retornar a sí mismo, por lo que o bien tiene wait como última orden, o añada exec a la última orden que es llamada y que no debe consistir en retornar (por ejemplo, llamar al gestor de ventanas).

La sesión utilizará su propio demonio dbus, pero varias utilidades systemd necesitarán la instancia dbus.service. Una posible solución a esto es crear alias para estas órdenes:

~/.bashrc
for sd_cmd in systemctl systemd-analyze systemd-run; do
    alias $sd_cmd='DBUS_SESSION_BUS_ADDRESS="unix:path=$XDG_RUNTIME_DIR/dbus/user_bus_socket" '$sd_cmd
done

Por último, active (como root) el servicio xlogin para iniciar automáticamente sesión al arrancar:

# systemctl enable xlogin@nombredeusuario

La sesión de usuario se desarrolla enteramente dentro de un espacio systemd y todo en la sesión de usuario debería funcionar bien.

Puesta en marcha automática de instancias de usuario de systemd

La instancia de usuario de systemd es, por defecto, ejecutada después del primer inicio de sesión de un usuario, pero, a veces, puede ser útil empezar aquella después del arranque. Lingering se utiliza para generar la instancia de usuario systemd en el arranque y que siga funcionando después del cierre de sesión.

Advertencia: Los servicios de systemd no son sesiones, se ejecutan fuera de logind. No utilice lingering para permitir el inicio de sesión automática, ya que rompe la sesión.

Utilice la siguiente orden para activar lingering para el usuario específico:

# loginctl enable-linger nombredeusuario

Configuración

Tango-view-refresh-red.pngThis article or section is out of date.Tango-view-refresh-red.png

Reason: After systemd 206, systemd --user mechanism has changed. (See [[3]], [[4]], [[5]]) (Discuss in Talk:Systemd/User (Español)#)

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