Discussion:
systemctl --user user can't restart their own service?
(too old to reply)
Jeff Solomon
2017-11-17 18:00:35 UTC
Permalink
Raw Message
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/***@.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?

Thanks,

Jeff
Kai Krakow
2017-11-17 22:52:10 UTC
Permalink
Raw Message
Am Fri, 17 Nov 2017 10:00:35 -0800
schrieb Jeff Solomon <***@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/***@.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 ***@.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 ***@.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.
Michael Chapman
2017-11-17 23:16:46 UTC
Permalink
Raw Message
On Sat, 18 Nov 2017, Jeff Solomon wrote:
> Hi,
>
> Is it by-design that a user can't restart their own user service?

If they aren't a lingering user, they'll get a new systemd instance if
they completely log out and back in again.

Alternatively, they can restart the running instance with:

systemctl --user daemon-reexec

This serializes state across the re-execution, so services running in the
instance are not killed.

There's few reasons a user might want to do this however. The only one I
can think of is where the admin had updated the systemd package and the
user wanted to make use of it immediately.
Jeff Solomon
2017-11-17 23:47:38 UTC
Permalink
Raw Message
When I run:

systemctl --user daemon-reexec

I see that the daemon gets a --deserialize flag in it command line on "top"
but the PID is not any different. I guess I don't need the PID to change if
the process picks up any changes to its unit file.

I would want to use this command for exactly the reason you specify
Michael. The ***@.service file might change and we want to make use of it
immediately. Also, we're only using lingering, so logging out and in
doesn't apply to us.

On Fri, Nov 17, 2017 at 3:16 PM, Michael Chapman <***@very.puzzling.org>
wrote:

> On Sat, 18 Nov 2017, Jeff Solomon wrote:
>
>> Hi,
>>
>> Is it by-design that a user can't restart their own user service?
>>
>
> If they aren't a lingering user, they'll get a new systemd instance if
> they completely log out and back in again.
>
> Alternatively, they can restart the running instance with:
>
> systemctl --user daemon-reexec
>
> This serializes state across the re-execution, so services running in the
> instance are not killed.
>
> There's few reasons a user might want to do this however. The only one I
> can think of is where the admin had updated the systemd package and the
> user wanted to make use of it immediately.
>
Michael Chapman
2017-11-18 00:21:59 UTC
Permalink
Raw Message
On Sat, 18 Nov 2017, Jeff Solomon wrote:
> When I run:
>
> systemctl --user daemon-reexec
>
> I see that the daemon gets a --deserialize flag in it command line on "top"
> but the PID is not any different. I guess I don't need the PID to change if
> the process picks up any changes to its unit file.

The systemd process simply reexecutes itself. It doesn't fork, so it
doesn't get a new PID.

> I would want to use this command for exactly the reason you specify
> Michael. The ***@.service file might change and we want to make use of it
> immediately. Also, we're only using lingering, so logging out and in
> doesn't apply to us.

This won't pick up changes to the ***@.service unit loaded into the
system-wide systemd instance. There shouldn't be any reason to change
this unit.
Loading...