Bug#887343: systemd-timesyncd does not start with DynamicUser=yes (requires libnss-systemd)

[Guido Günther]

Hi Michael,
On Mon, Jan 15, 2018 at 12:44:34PM +0100, Michael Biebl wrote:
> Hi Guido
> 
> Am 15.01.2018 um 12:14 schrieb Guido Günther:
> > Hi,
> > On Mon, Jan 15, 2018 at 11:24:33AM +0100, Michael Biebl wrote:
> >> Am 15.01.2018 um 10:18 schrieb Guido Günther:
> 
> >> It requires libnss-systemd, yes. Do you not have it installed?
> >> It's a recommends, so should be installed by default
> > 
> > See above: "without installing recommends". My whole point is that the
> 
> Ok, just wanted to make 100% sure libnss-systemd was not installed. Even
> with recommends disabled, it might have been installed.
> 
> > systemd package installs a service that won't even start without the
> > recommends which looks somewhat wrong to me. I would expect that
> > 
> >     systemctl list-units --failed
> > 
> > would not contain any failed systemd units even without installing
> > recommends. If you think this is all wrong free to close it.
> 
> My first instinct was to say, if you disable recommends, then you should
> know what you do and it's up to the user to deal with the results.
> 
> Then again, systemd (or rather systemd-sysv, which recommends
> libnss-systemd) is special, as it is installed by d-i at a stage where
> recommends are apparently not considered yet.
> I know too little about the d-i internals, but I've just tested with the
> latest buster d-i daily image, and after the system installation,
> libnss-systemd was indeed missing.

To me it happened with vmdeboostrap and then installing without
recommends (which doesn't seem so uncommon either given the examples
that float around on the net).

> I vaguely remember that we had the same issue with libpam-systemd.
> We wanted to make it possible to not libpam-systemd so chose a
> Recommends but also noticed, that it was not installed by d-i. Which is
> why we bumped the severity of libpam-systemd to standard, so it would be
> installed at a later stage by the "standard" task.
> 
> We could do the same for libnss-systemd.
> But somehow I think it would be better to just bite the bullet and
> upgrade it to a hard dependency. DynamicUser=yes is a feature which we
> expect will be used more frequently in the future (also by other
> packages) and should just work ootb imho.

That would IMHO be the best solution. DynamicUser=yes is nice and if we
want to use it more (maybe even in non-systemd packages) it will be
pulled in anyway.

> libnss-systemd doesn't pull in any additional dependencies and weighs
> about 350K.
> Do we have convincing use cases where it would be beneficial to not have
> libnss-systemd installed?

Absolutely not ;)

> Thoughts?

Turning it into a dependency would probably be best. It might be
sufficient to have it as a dependency of systemd-sysv, not systemd
itself.

Cheers,
 -- Guido