configuring /var/run with newer autoconf

configuring /var/run with newer autoconf

[Łukasz Stelmach]

[-- Attachment #1: Type: text/plain, Size: 1312 bytes --]

Hi,

TL;DR Is there a chance a patch requiring autconf 2.70 is going to be
      accepted?

I found myself in trouble because of a deadlock during boot (on
Linux). In short: the deadlock happens if I want to make /var
automountable because.

a) systemd controls controls automounts.

b) To mount a file-system systemd needs to know about the underlying
   block device.

c) udev tells systemd about devices available.

d) When udev starts it tries to make some queries via NSS which means
   connecting to nscd (/var/run/nscd/socket, hardcoded in nscd-client.h)

Effect: I can't configure /var to be automounted.

Solutions:

a) Compile glibc without nscd support. This works for me, now.

b) Make the path configurable so Linux systems, especially those
   controlled by systemd which requires /var/run to be a symlink
   pointing to /run which is mounted by systemd as tmpfs, can use /run
   instead of /var/run.

Sollution b) should be quite simple to implement. However, there is one
condition: use autoconf 2.70 which introduces runstatedir variable. I'd
like to prepare the patch but I need to know if there is a chance it is
going to be accepted if it introduces such dependency?

Kind regards,
-- 
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

Re: configuring /var/run with newer autoconf

[Joseph Myers]

[-- Attachment #1: Type: text/plain, Size: 1079 bytes --]

On Thu, 7 Apr 2016, Łukasz Stelmach wrote:

> Hi,
> 
> TL;DR Is there a chance a patch requiring autconf 2.70 is going to be
>       accepted?

I don't think it's appropriate to require unreleased versions of external 
packages.  A proposal to use autoconf 2.70 should wait until it's been 
released.  (And until it's widely present in GNU/Linux distributions I 
think pretty strong justification would be needed to use it, even after 
it's been released.)

I'm also doubtful that making the /var/run path configurable is an 
appropriate change at all.  This path appears in _PATH_VARRUN in 
sysdeps/unix/sysv/linux/paths.h, an installed header.  In general it's 
best for installed headers to depend only on the (architecture, OS) pair 
(with architecture being interpreted so that e.g. 32-bit and 64-bit get 
the same headers), not on other configuration variants.  If there is 
consensus on /run being the right path on GNU/Linux, then the change 
should simply be made unconditionally (with appropriate documentation in 
NEWS).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: configuring /var/run with newer autoconf

[Mike Frysinger]

[-- Attachment #1: Type: text/plain, Size: 1283 bytes --]

On 07 Apr 2016 16:49, Łukasz Stelmach wrote:
> TL;DR Is there a chance a patch requiring autconf 2.70 is going to be
>       accepted?
> 
> I found myself in trouble because of a deadlock during boot (on
> Linux). In short: the deadlock happens if I want to make /var
> automountable because.
> 
> a) systemd controls controls automounts.
> 
> b) To mount a file-system systemd needs to know about the underlying
>    block device.
> 
> c) udev tells systemd about devices available.
> 
> d) When udev starts it tries to make some queries via NSS which means
>    connecting to nscd (/var/run/nscd/socket, hardcoded in nscd-client.h)
> 
> Effect: I can't configure /var to be automounted.
> 
> Solutions:
> 
> a) Compile glibc without nscd support. This works for me, now.
> 
> b) Make the path configurable so Linux systems, especially those
>    controlled by systemd which requires /var/run to be a symlink
>    pointing to /run which is mounted by systemd as tmpfs, can use /run
>    instead of /var/run.

b) has been discussed here in the past and declined:
	https://sourceware.org/ml/libc-alpha/2015-03/msg00828.html

but you also have another option and what most people have been doing:
c) symlink /var/run to /run

problem solved
-mike

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: configuring /var/run with newer autoconf

[Łukasz Stelmach]

[-- Attachment #1: Type: text/plain, Size: 1568 bytes --]

It was <2016-04-07 czw 17:14>, when Joseph Myers wrote:
> On Thu, 7 Apr 2016, Łukasz Stelmach wrote:
>
>> Hi,
>> 
>> TL;DR Is there a chance a patch requiring autconf 2.70 is going to be
>>       accepted?
>
> I don't think it's appropriate to require unreleased versions of external 
> packages.

I agree. I wrote about 2.70 before finding out it hasn't been released
yet.


> I'm also doubtful that making the /var/run path configurable is an 
> appropriate change at all.  This path appears in _PATH_VARRUN in 
> sysdeps/unix/sysv/linux/paths.h, an installed header.

And sysdeps/generic/paths.h and nowhere else. OK, I assume it is a part
API and changing it can break software compiled with different headers.

> In general it's best for installed headers to depend only on the
> (architecture, OS) pair (with architecture being interpreted so that
> e.g. 32-bit and 64-bit get the same headers), not on other
> configuration variants.  If there is consensus on /run being the right
> path on GNU/Linux, then the change should simply be made
> unconditionally (with appropriate documentation in NEWS).

All you write is valid. Unfortunately this does not bring me any closer
to solving the nscd+automount deadlock. Can you think of any solution
that allows:

a) configuring /var as mounted via autofs and

b) to avoid software lock-ups when programmes unconditionally try to
   connect to nscd and

c) not to disable nscd entirely?

Kind regards,
-- 
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

Re: configuring /var/run with newer autoconf

[Łukasz Stelmach]

[-- Attachment #1: Type: text/plain, Size: 1490 bytes --]

It was <2016-04-07 czw 19:51>, when Mike Frysinger wrote:
> On 07 Apr 2016 16:49, Łukasz Stelmach wrote:
>> TL;DR Is there a chance a patch requiring autconf 2.70 is going to be
>>       accepted?
>> 
>> I found myself in trouble because of a deadlock during boot (on
>> Linux). In short: the deadlock happens if I want to make /var
>> automountable because.
>> 
>> a) systemd controls controls automounts.
>> 
>> b) To mount a file-system systemd needs to know about the underlying
>>    block device.
>> 
>> c) udev tells systemd about devices available.
>> 
>> d) When udev starts it tries to make some queries via NSS which means
>>    connecting to nscd (/var/run/nscd/socket, hardcoded in nscd-client.h)
>> 
>> Effect: I can't configure /var to be automounted.
>> 
>> Solutions:
>> 
>> a) Compile glibc without nscd support. This works for me, now.
>> 
>> b) Make the path configurable so Linux systems, especially those
>>    controlled by systemd which requires /var/run to be a symlink
>>    pointing to /run which is mounted by systemd as tmpfs, can use /run
>>    instead of /var/run.
>
> b) has been discussed here in the past and declined:
> 	https://sourceware.org/ml/libc-alpha/2015-03/msg00828.html

I see.

> but you also have another option and what most people have been doing:
> c) symlink /var/run to /run

This does not help to avoid deadlocks at all.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

Re: configuring /var/run with newer autoconf

[Florian Weimer]

On 04/08/2016 09:52 AM, Łukasz Stelmach wrote:

>> but you also have another option and what most people have been 
>> doing: c) symlink /var/run to /run
> 
> This does not help to avoid deadlocks at all.

Why?  It may need changes to autofs, so that it can produce the
required symbolic link, at an early stage of operation.

Florian

Re: configuring /var/run with newer autoconf

[Segher Boessenkool]

On Fri, Apr 08, 2016 at 09:52:36AM +0200, Łukasz Stelmach wrote:
> > but you also have another option and what most people have been doing:
> > c) symlink /var/run to /run
> 
> This does not help to avoid deadlocks at all.

You can put the /var/run symlink on the root fs (as well as on the /var fs),
so that it is available before the mount of /var as well.


Segher

Re: configuring /var/run with newer autoconf

[Łukasz Stelmach]

[-- Attachment #1: Type: text/plain, Size: 887 bytes --]

It was <2016-04-11 pon 02:05>, when Segher Boessenkool wrote:
> On Fri, Apr 08, 2016 at 09:52:36AM +0200, Łukasz Stelmach wrote:
>> > but you also have another option and what most people have been doing:
>> > c) symlink /var/run to /run
>> 
>> This does not help to avoid deadlocks at all.
>
> You can put the /var/run symlink on the root fs (as well as on the /var fs),
> so that it is available before the mount of /var as well.

No go. Among all other differences in one point autofs behaves like any
other filesystem, it covers the contents of a directory it is mounted
in. This means that the /var/run symlink on the root filesystem is not
visible after setting up an "auto-mountpoing" (mounting autofs) and any
requests are meant to be satisfied after mounting the real /var
filesystem.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

Re: configuring /var/run with newer autoconf

[Łukasz Stelmach]

[-- Attachment #1: Type: text/plain, Size: 901 bytes --]

It was <2016-04-08 pią 14:31>, when Florian Weimer wrote:
> On 04/08/2016 09:52 AM, Łukasz Stelmach wrote:
>
>>> but you also have another option and what most people have been 
>>> doing: c) symlink /var/run to /run
>> 
>> This does not help to avoid deadlocks at all.
>
> Why?  It may need changes to autofs, so that it can produce the
> required symbolic link, at an early stage of operation.

autofs works as expected, it does not provide any contents itself, instead it
intercepts all requests and put them on hold until the actual filesystem
is mounted. I wouldn't expect anything else.

I'd say the case we are discussing is an extremely rare corner case for
autofs and I'd rather expect requirement for autoconf 2.70 be accepted
in libc (-; before any kernel developer accepts a patch for autofs.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

Re: configuring /var/run with newer autoconf

[Florian Weimer]

On 04/11/2016 09:20 AM, Łukasz Stelmach wrote:
> It was <2016-04-08 piÄ… 14:31>, when Florian Weimer wrote:
>> On 04/08/2016 09:52 AM, Łukasz Stelmach wrote:
>>
>>>> but you also have another option and what most people have been
>>>> doing: c) symlink /var/run to /run
>>>
>>> This does not help to avoid deadlocks at all.
>>
>> Why?  It may need changes to autofs, so that it can produce the
>> required symbolic link, at an early stage of operation.
>
> autofs works as expected, it does not provide any contents itself, instead it
> intercepts all requests and put them on hold until the actual filesystem
> is mounted. I wouldn't expect anything else.

For generating the symlinks in /var, I would expect to provide them.

Are you trying to automount /var itself, or is /var a directory 
monitored by the automounter?

> I'd say the case we are discussing is an extremely rare corner case for
> autofs and I'd rather expect requirement for autoconf 2.70 be accepted
> in libc (-; before any kernel developer accepts a patch for autofs.

It's not just autoconf (which, as far as I understand it, is not 
released at this point).   The pathname is part of the ABI, so we can't 
really change it for existing architectures.

Florian

Re: configuring /var/run with newer autoconf

[Łukasz Stelmach]

[-- Attachment #1: Type: text/plain, Size: 2341 bytes --]

It was <2016-04-11 pon 18:09>, when Florian Weimer wrote:
> On 04/11/2016 09:20 AM, Łukasz Stelmach wrote:
>> It was <2016-04-08 pią 14:31>, when Florian Weimer wrote:
>>> On 04/08/2016 09:52 AM, Łukasz Stelmach wrote:
>>>
>>>>> but you also have another option and what most people have been
>>>>> doing: c) symlink /var/run to /run
>>>>
>>>> This does not help to avoid deadlocks at all.
>>>
>>> Why?  It may need changes to autofs, so that it can produce the
>>> required symbolic link, at an early stage of operation.
>>
>> autofs works as expected, it does not provide any contents itself, instead it
>> intercepts all requests and put them on hold until the actual filesystem
>> is mounted. I wouldn't expect anything else.
>
> For generating the symlinks in /var, I would expect to provide them.
>
> 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.

>> I'd say the case we are discussing is an extremely rare corner case for
>> autofs and I'd rather expect requirement for autoconf 2.70 be accepted
>> in libc (-; before any kernel developer accepts a patch for autofs.
>
> It's not just autoconf (which, as far as I understand it, is not
> released at this point).   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.

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

Re: configuring /var/run with newer autoconf

[Florian Weimer]

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.

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

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

Florian

Re: configuring /var/run with newer autoconf

[Andreas Schwab]

Łukasz Stelmach <l.stelmach@samsung.com> writes:

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

_PATH_NSCDSOCKET is part of the ABI, it is used by libc to contact nscd.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: configuring /var/run with newer autoconf

[Łukasz Stelmach]

[-- Attachment #1: Type: text/plain, Size: 2666 bytes --]

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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

Re: configuring /var/run with newer autoconf

[Łukasz Stelmach]

[-- Attachment #1: Type: text/plain, Size: 2040 bytes --]

It was <2016-04-12 wto 10:55>, when Andreas Schwab wrote:
> Łukasz Stelmach <l.stelmach@samsung.com> writes:
>
>> 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.
>
> _PATH_NSCDSOCKET is part of the ABI, it is used by libc to contact nscd.

The second part of the above sentence is definitely true. I am not so
sure about the truth of the first part (I am not very familiar with
conventions and contracts in glibc so I may be making mistakes or
writing outright BS, please correct me then).

Assuming it is (and I am not so sure) let's try to find out what uses
it. The symbol appears in three source code files and one header file
all in the nscd/ directory. The code using the symbol is hooked in nscd
itself (not a problem) and in a single[*] place libc.so.6.

Usually nscd binary comes from the same source as libc and there is
little risk of mismatch between nscd listening to /run/nscd/socket and
libc connecting to /var/run/nscd/socket.

Now some stupid questions. How does glibc declare its ABI? What makes a
defined constant like _PATH_NSCDSOCKET a part of the ABI? For example
_PATH_VARRUN is defined in public headers I can find in my
/usr/include/paths.h. On the other hand I can't find _PATH_NSCDSOCKET
anywhere in my /usr/include so I suppose no other code than libc is
using this value, hence it is not ABI.

[*] I assume it by observing the "/var/run/nscd/socket" string being
stored in the .text section and loaded funnily with movabs instructions
(on x86-64)
-- 
Łukasz Stelmach
Samsung R&D Institute Poland
Samsung Electronics

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]