[systemd-devel] Running ldconfig at boot

[Florian Weimer]

On 05/23/2016 11:59 AM, Lennart Poettering wrote:
> On Mon, 23.05.16 11:34, Florian Weimer (fweimer at redhat.com) wrote:
>
>> 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)?
>
> Well, I'd claim that expecting that if you install libraries on mounts
> not included in local-fs.target they still appear in ldconfig is
> wrong. I mean, the promise "local-fs.target" makes is that that's all
> needed for services to run, and for upgrades of the OS to take
> place.

That's not what the documentation in systemd.special(7) says.  It 
essentially defines local-fs.target based on file system type.  It says 
nothing about service availability.

I expect there are still installations out there which run /opt (or 
something like it) off NFS.

>> 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.
>
> I am not sure I grok why uuids would be a better option than mtimes here...

Time-base synchronization tends to cause problems.  If /etc is modified 
before the system time is set from NTP, you get an incorrect timestamp. 
If /usr goes backwards in time, you don't run the update actions.  And 
the update actions are triggered by unexpected package installations.

If you used a UUID file instead, you could (a) mark /usr as externally 
supplied and (b) avoid all issues related to clock skew.

Florian