On 05/23/2016 11:59 AM, Lennart Poettering wrote:
On Mon, 23.05.16 11:34, Florian Weimer (fwei...@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
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
