[systemd-devel] Running ldconfig at boot

[Florian Weimer]

On 05/20/2016 04:10 PM, Lennart Poettering wrote:

>> 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.

Hmm.  And this is sufficient justification to force ldconfig.service on 
all users by default, despite its impact on correctness (see below) and 
boot time (as reported on this thread as well)?

>>>> 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?

Not all local and *remote* file systems, yes.  I can't rule out that 
there are deployments which require that network file systems are 
mounted before the cache can be updated to a correct state.

“ldconfig -X” currently does not behave in the way you assumed it does. 
This means that running ldconfig too learly changes ld.so semantics 
(breaking systems).  It is not just a performance optimization.

> 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 think the trigger is just implemented incorrectly.  It should keep 
track of UUIDs in files (such as /usr/.change-uuid), rather than looking 
at mtimes.  Then you can just write a new UUID once you update parts of 
the file system externally and completely avoid running such triggers 
when all subtrees are locally maintained.

Thanks,
Florian