Discussion:
Start a global service
Add Reply
Damien Robert
2017-02-15 16:58:02 UTC
Reply
Permalink
Raw Message
1) Feature request

I would like a way [as root] to start a service on all active user sessions.
Typically to start a user service that was installed globally.

sudo systemctl --global start myservice.service

will start myservice.service as a root user service, not on the other user
sessions.

2) Feature request

Something that could be usefull too is a special target (both for the user
and system sessions) that is started automatically when there is ac loss,
so that we run on battery, and conversely. We could even imagine systemd
calling hooks like for systemd-sleep.

It is of course not hard to do that on the system session with a udev rule,
but I don't know how to start one automatically on the user sessions (hence
my feature request above).

I call my targets power-save.target and power-performance.target, but the
name may not be generic enough, maybe something like ac-loss.target,
ac-gain.target?

3) Usage

Here is my current implementation of a system wide special power-save target.

- In /etc/udev/rules.d, a rule:
ACTION=="change", SUBSYSTEM=="power_supply", ENV{POWER_SUPPLY_ONLINE}=="[01]", RUN+="/usr/local/lib/powersave/bin/power-dispatcher %E{POWER_SUPPLY_ONLINE}"

- power-dispatcher:
if (($1)); then # 1 = plug
systemctl --no-block start power-performance.target
else # 0 = battery
systemctl --no-block start power-save.target
fi

- power-performance.target:
[Unit]
Description=System power management: performance mode
Conflicts=power-save.target

- power-save.target:
[Unit]
Description=System power management: power-saving mode
Conflicts=power-performance.target
After=power-performance.target

- power-save.service:
[Unit]
Description=Powersave mode (global service)
PartOf=power-save.target

[Service]
Type=oneshot
RemainAfterExit=true
ExecStartPre=-/usr/bin/sleep 10
ExecStart=/usr/local/lib/powersave/bin/powersave true

[Install]
WantedBy=power-save.target

- power-performance.service:
[Unit]
Description=Power performance mode (global service)
PartOf=power-performance.target

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/usr/local/lib/powersave/bin/powersave false

[Install]
WantedBy=power-performance.target

Note: the sleep 10 in power-save.service is that in case of <10s ac loss, like happen often in trains or planes the powersave settings do not get applied.

And it works very well!

However for X display settings like 'xset +dpms', it would make more sense
to run this as part of the user session, which has access to DISPLAY and
XAUTHORITY. It is not too hard to find the active display as roots, but the
DISPLAY without the XAUTHORITY is not enough (unless the user adds a 'xhost
+si:localuser:$(id -un) somewhere'). So I could try to find which user is
using which X display and find their .Xauthority but it gets cumbersome.

Thanks,
Damien Robert
Lennart Poettering
2017-02-15 17:21:59 UTC
Reply
Permalink
Raw Message
Post by Damien Robert
1) Feature request
I would like a way [as root] to start a service on all active user sessions.
Typically to start a user service that was installed globally.
sudo systemctl --global start myservice.service
will start myservice.service as a root user service, not on the other user
sessions.
Sorry, but this is unlikely to be added. I understand that this would
be handy, but this is semantically very questionable, as this would be
transition from privileged code into unprivileged code, and that's
something we can't really have.
Post by Damien Robert
2) Feature request
Something that could be usefull too is a special target (both for the user
and system sessions) that is started automatically when there is ac loss,
so that we run on battery, and conversely. We could even imagine systemd
calling hooks like for systemd-sleep.
systemd is not really a battery manager, use services like upower for
that, which do provide similar hooks.

Lennart
--
Lennart Poettering, Red Hat
Damien Robert
2017-02-15 17:53:53 UTC
Reply
Permalink
Raw Message
Lennart Poettering wrote in message
Sorry, but this is unlikely to be added. I understand that this would be
handy, but this is semantically very questionable, as this would be
transition from privileged code into unprivileged code, and that's
something we can't really have.
Ok, I understand, I'll just parse /run/user/*/systemd to get the active
users (loginctl list-users is not very machine friendly)
systemd is not really a battery manager, use services like upower for
that, which do provide similar hooks.
Fair enough. But I don't really see the point to have a daemon that will
just listen to udev events for power change (udevd does other things which
I do not need). I prefer my solution which calls directly systemd services.

Thanks,
Damien Robert
Reindl Harald
2017-02-15 17:59:44 UTC
Reply
Permalink
Raw Message
Post by Damien Robert
Lennart Poettering wrote in message
Sorry, but this is unlikely to be added. I understand that this would be
handy, but this is semantically very questionable, as this would be
transition from privileged code into unprivileged code, and that's
something we can't really have.
Ok, I understand, I'll just parse /run/user/*/systemd to get the active
users (loginctl list-users is not very machine friendly)
systemd is not really a battery manager, use services like upower for
that, which do provide similar hooks.
Fair enough. But I don't really see the point to have a daemon that will
just listen to udev events for power change (udevd does other things which
I do not need). I prefer my solution which calls directly systemd services.
the point is that daemon is desigend to care about that and nothing else
and you just need the right hooks - what is the point to fireup a system
service for each active user? abuse systemd to do as your inital post
proposed would make it a chimere i don't want to run on any of my
systems (and i am not a systemd developer)
Damien Robert
2017-02-15 18:33:53 UTC
Reply
Permalink
Raw Message
Sorry I meant upower rather than udevd in my message.

Reindl Harald wrote in message
Post by Reindl Harald
the point is that daemon is desigend to care about that and nothing else
and you just need the right hooks - what is the point to fireup a system
service for each active user? abuse systemd to do as your inital post
proposed would make it a chimere i don't want to run on any of my
systems (and i am not a systemd developer)
Sure I already said I understood why Lennart's does not want to add these
features. This is not a problem, I can use a bit of shell code to simulate
it. You might find it ugly, I don't; no need to be rude about it.
Loading...