[systemd-devel] Running ldconfig at boot

[Lennart Poettering]

On Fri, 20.05.16 16:06, Florian Weimer (fweimer at redhat.com) wrote:

> On 05/20/2016 04:04 PM, Lennart Poettering wrote:
> >On Fri, 20.05.16 15:55, Florian Weimer (fweimer at redhat.com) wrote:
> >
> >>On 05/20/2016 02:59 PM, Lennart Poettering wrote:
> >>>On Fri, 20.05.16 14:01, Florian Weimer (fweimer at redhat.com) wrote:
> >>>
> >>>>The default systemd configuration runs ldconfig at boot.  Why?
> >>>
> >>>It's conditionalized via ConditionNeedsUpdate=, which means it is only
> >>>run when /etc is older than /usr. (This is tested via checking
> >>>modification times of /etc/.updated and /usr), see explanation on
> >>>systemd.unit(5).
> >>>
> >>>The usecase for this is to permit systems where a single /usr tree is
> >>>shared among multiple systems, and might be updated at any time, and
> >>>the changes need to be propagated to /etc on each individual
> >>>systems. The keyword is "stateless systems".
> >>
> >>Do such systems need systemd configuration changes?
> >
> >Not sure I understand this question?
> 
> If such systems require specialized unit files, then you can put
> ldconfig.service there, instead of exposing all systemd users to the
> service.

No they don't. Basic Fedora works fine in this mode, without any
changes. It isn#t round, and it isn't supported fully by Fedora, but
the basics do work just fine.

> >>There are some more packages where installation or upgrades would update the
> >>/usr mtime.  I don't have a current Fedora rawhide list, but I'm attaching
> >>an older version.  The /usr mtime is not a reliable indicator for what you
> >>are trying to detect, I think.
> >
> >Well, it really doesn't have to be. I mean, in the worst case we'll
> >run ldconfig once too often, which should be idempotent...
> 
> As I explained, the way you run it, it is not necessarily idempotent.

You mean, because not all local file systems have been mounted yet?

So, there was actually a PR that tried to fix that, posted recently:

    https://github.com/systemd/systemd/pull/2859

and it was merged recently, too. But it broke precisely the reason why
the service exists at all, because it did more than just fix the local
fs thing, and removed the update trigger...

I filed a PR to revert that PR now:

    https://github.com/systemd/systemd/pull/3305

I figure an independent PR should be filed to restore the local-fs
thing then...

Lennart

-- 
Lennart Poettering, Red Hat