This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: configuring /var/run with newer autoconf


It was <2016-04-12 wto 10:50>, when Florian Weimer wrote:
> On 04/12/2016 10:41 AM, Åukasz Stelmach wrote:
>
>>> Are you trying to automount /var itself, or is /var a directory
>>> monitored by the automounter?
>>
>> I don't exactly understand the alternative. Let me try to describe what
>> happens in my system.
>>
>> I've got a root fs. There is the /var directory. It is empty. There is
>>
>>      LABEL=var    /var    ext4    defaults,noatime,x-systemd.automount    0 2
>>
>> line in my fstab. x-systemd.automount tells systemd to mount autofs
>> under /var, start monitoring it for requests and mount the real ext4
>> file-system when a request comes.
>
> The traditional use of an automounter is that you have a file system
> directory, such as /mnt, which contains several remote file systems,
> and each one is mounted on demand once you access the path.
>
> Instead, you seem to be using the automounter to mount just a single
> directory.

Actually automounters (both nfs based and autofs based) has always been
used to mount single directory. To have several directories mounted in
/mnt one had to create those directories there and monitor each one of
them individually.

> May I ask what is the reason for delayed mounting of /var?

It's about making the startup process parallel. Setting up autofs is
much quicker than mounting a block-device-backed and lets all programmes
(except udev) willing to access /var be started. When they are running
they block until /var is mounted and let CPU scheduller assign time to
other tasks that do not access /var. And actually it makes my system
start faster.

>>> The pathname is part of the ABI, so we
>>> can't really change it for existing architectures.
>>
>> I am not sure this is actually true. What is a part of ABI (as far as I
>> understand it) is _PATH_VARRUN defined in sysdeps/generic/paths.h and
>> sysdeps/unix/sysv/linux/paths.h. However, this isn't what nscd
>> uses. nscd has its own definitions in nscd/nscd-client.h and nscd/nscd.h
>> which apparently are not exported to /usr/include and are not supposed
>> to be used outside nscd. That means it should be possible to change the
>> the location wher nscd keeps its stuff without breaking ABI.
>
> nscd is only the tip of the iceberg.  Many NSS modules reference paths
> under /var (such as /var/db, /var/run, or /var/lib/sss).

Indeed, however I am not interested in any other path than /var/run
(which is a symlink to /run anyway) and paths in nscd seem to be
"self contained" and independent of any other.

-- 
Åukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics

Attachment: signature.asc
Description: PGP signature


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]