<div dir="ltr"><div>When I run:</div><div><br></div><div>    systemctl --user daemon-reexec</div><div><br></div><div>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.</div><div><br></div><div>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.<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 17, 2017 at 3:16 PM, Michael Chapman <span dir="ltr"><<a href="mailto:mike@very.puzzling.org" target="_blank">mike@very.puzzling.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Sat, 18 Nov 2017, Jeff Solomon wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
Is it by-design that a user can't restart their own user service?<br>
</blockquote>
<br></span>
If they aren't a lingering user, they'll get a new systemd instance if they completely log out and back in again.<br>
<br>
Alternatively, they can restart the running instance with:<br>
<br>
  systemctl --user daemon-reexec<br>
<br>
This serializes state across the re-execution, so services running in the instance are not killed.<br>
<br>
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.<br>
</blockquote></div><br></div>