<div dir="ltr">Control: forwarded -1 <a href="https://github.com/systemd/systemd/issues/7883">https://github.com/systemd/systemd/issues/7883</a><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 15, 2018 at 8:57 AM, Martin Pitt <span dir="ltr"><<a href="mailto:mpitt@debian.org" target="_blank">mpitt@debian.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Guido Günther [2018-01-15 12:14 +0100]:<br>
<span class="gmail-">> > > This seems to be caused by the fact that libnss-systemd is not a hard<br>
> > > dependency of systemd. I'm not sure what the best solution is? Having a<br>
> > > service that is enabled by fails to start looks weird though. Maybe<br>
> > > providing a static user isn't that bad?<br>
> > ><br>
> ><br>
> > It requires libnss-systemd, yes. Do you not have it installed?<br>
> > It's a recommends, so should be installed by default<br>
><br>
> See above: "without installing recommends". My whole point is that the<br>
> systemd package installs a service that won't even start without the<br>
> recommends which looks somewhat wrong to me.<br>
<br>
</span>Note that *in general*, DynamicUser=yes does not *require* libnss-systemd.<br>
Services start without it, the only effect is that showing the process with<br>
tools like "ps" will not be able to resolve a dynamic user ID to a name - it<br>
will just be shown as an ID. This might be a bit confusing, but acceptable for<br>
some environments, hence I just made it a Recommends:, not a Depends:.<br>
<br>
If timesyncd in particular somehow wants to resolve the systemd-timesyncd<br>
system user in its own code, then that either should be fixed, or systemd needs<br>
to raise libnss-systemd to a Depends: for that particular bug/reason.<br></blockquote><div><br></div><div>It appears timesyncd wants to do this to support being run as root and then dropping privileges. However, this will fail in the DynamicUser=yes world because systemd-timesync user won't exist if we are not running the service. I'm not sure it makes sense anymore to support that usecase, so I have filed the issue upstream.</div><div><br></div></div>-- <br><div class="gmail_signature"><br>Saludos,<br>Felipe Sateler</div>
</div></div>