[systemd-devel] systemctl --user user can't restart their own service?

[Kai Krakow]

Am Fri, 17 Nov 2017 10:00:35 -0800
schrieb Jeff Solomon <jsolomon8080 at gmail.com>:

> Hi,
> 
> Is it by-design that a user can't restart their own user service?
> 
> I have worked around this by doing the following:
> 
> Override /lib/systemd/system/user at .service with a new file:
> 
> /etc/systemd/system/user@<uid>.service
> 
> I could have left out the <uid> if I wanted the override to apply to
> all users, but in this case, I want it to apply to only a single user.
> 
> In user@<uid>.service, I added:
> 
> Restart=always
> 
> to the [Service] section.
> 
> Viola! Now the user can just kill their own service (since they own it
> after all) and systemd will restart it for them.
> 
> Any problem with this workaround Lennart?

Services in systemd/system are NOT user services. It's a system service
running with user privileges. I think the whole point of exactly that
instance is starting the user systemd instance.

Real user services belong into systemd/user folder (provided by the
admin or system, or by the user when below $HOME/.config).

With "systemctl --user" you manage exactly those services.

What's the point of letting the user restart the user at .service anyway?
It would probably kill her/his login session or break other things. You
should restart individual user services instead. You can list them with
"systemctl --user status".

I have the feeling you didn't understand what the user at .service really
is... It's in any case not "the user's own service". It's their systemd
instance. It is to your user login what is init to the OS. You wouldn't
restart init, would you? I probably understand that it'd be equal to
rebooting the system. Thus, in the user instance case, it would restart
the complete session of the user.

You have to understand the difference: You could also create a service
like dropbox@<uid>.service. But it's not a user service then. It's a
system service instance running with user privileges. It's in that case
decoupled from the user session and would run without having the user
to login. You can achieve something similar with enabling linger on user
sessions. The difference is: First case runs outside of the user
session context, the latter runs within the context. This has a direct
effect on how the cgroups apply.


-- 
Regards,
Kai

Replies to list-only preferred.