[systemd-devel] systemctl --user user can't restart their own service?
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@.service with a new file: /etc/systemd/system/user@.service I could have left out the 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@.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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemctl --user user can't restart their own service?
Am Fri, 17 Nov 2017 10:00:35 -0800 schrieb Jeff Solomon : > 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@.service with a new file: > > /etc/systemd/system/user@.service > > I could have left out the 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@.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@.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@.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@.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. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemctl --user user can't restart their own service?
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. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemctl --user user can't restart their own service?
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 user@.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 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. > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemctl --user user can't restart their own service?
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 user@.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 user@.service unit loaded into the system-wide systemd instance. There shouldn't be any reason to change this unit. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel