Acabo de terminar el proceso de instalación y configuración de systemd en mi sistema arch-linux (2012.09.07). Desinstalé initscripts
(y eliminé los archivos de configuración).
Lo que quiero hacer es crear un servicio que pueda ser iniciado y detenido por un usuario no root. El servicio es para iniciar una sesión de pantalla separada ejecutando rtorrent. Sin embargo, quiero que cada usuario del sistema que haya configurado este servicio para que se inicie (habilite) tenga una instancia particular iniciada específicamente para ellos. ¿Cómo se podría hacer esto?
Recuerdo haber leído que systemd admite instancias de servicios para usuarios, sin embargo, no he podido encontrar ninguna información sobre cómo configurar esto o si se relaciona con lo que estoy buscando.
Archivo de servicio que he usado para el sistema:
[Unit]
Description=rTorrent
[Service]
Type=forking
ExecStart=/usr/bin/screen -d -m -S rtorrent /usr/bin/rtorrent
ExecStop=/usr/bin/killall -w -s 2 /usr/bin/rtorrent
ACTUALIZACIÓN # 1 :
Después de leer las páginas de manual aquí y aquí , entiendo cómo systemd funciona un poco mejor. Específicamente, el uso de las opciones User=
y WorkingDirectory=
permite que el servicio se inicie en la sesión de un usuario. Sin embargo, el problema sigue siendo que el propio usuario no puede start
, stop
, enable
, o disable
el servicio. Un error de acceso denegado es dado por systemctl
.
ACTUALIZACIÓN # 2 :
En primer lugar, para simplificar y para un mejor uso de la función de sesión de usuario de systemd (todavía algo incompleta), utilicé las unidades de sesión de usuario de sofar y seguí sus consejos de configuración.
Parece que hay un error en la versión actual de DBus (1.6.4-1) en el que no establece la variable de entorno, lo que DBUS_SESSION_BUS_ADDRESS
significa usar los systemctl --user
errores de comando con:
Failed to get D-Bus connection: Unable to autolaunch a dbus-daemon without a $DISPLAY for X11
La variable debería verse así:
DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/USERUID/dbus/user_bus_socket"
donde USERUID debe ser el UID del usuario dado.
sudo
para los usuarios y hacer que, como se menciona en mi comentario anterior, controlen su propio archivo de servicio. Sin embargo, esta solución permitiría al usuario controlar la mayoría de los otros servicios también ...
sudo
la documentación, sudoers (5) tiene muchos ejemplos sobre cómo restringir los argumentos de un comando.