[systemd-devel] Running ldconfig at boot

[Lennart Poettering]

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. THis is cooked into a multitude of services, including
PackageKit, various yum services, and the concept of "offline updates"
that fedora currently implements. "local-fs.target" is supposed to
include everything necessary to run user code, it's its very
definition.

Hence: systemd is correct here, really.

Users who split out libraries into mounts only available later or
during runtime, and who expect them to appear in the ld.so cache
already have to manually schedule their "yum upgrade" lines, and they
cannot make use of offline updates, nor of packagekit or many other
packaging scripts. I think it's completely OK to expect from them to
also run "systemctl mask ldconfig" in this case.

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

I am not sure I grok why uuids would be a better option than mtimes here...

Lennart

-- 
Lennart Poettering, Red Hat