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: misc/tst-ttyname time outs


* Carlos O'Donell:

> On 1/2/19 9:48 AM, Florian Weimer wrote:
>> * Szabolcs Nagy:
>> 
>>> in run_chroot_tests the following loop time outs for me:
>>>
>>>     /* keep creating PTYs until we we get a name collision */
>>>     while (stat (slavename, &st) < 0)
>>>       posix_openpt (O_RDWR|O_NOCTTY|O_NONBLOCK);
>>>
>>> it seems posix_openpt can fail with EMFILE or ENOSPC in the
>>> loop and then it never finishes.
>>>
>>> example strace:
>>> [pid 24510] newfstatat(AT_FDCWD, "/dev/pts/1789", 0xffffdd528fe0, 0) = -1 ENOENT (No such file or directory)
>>> [pid 24510] openat(AT_FDCWD, "/dev/ptmx", O_RDWR|O_NOCTTY|O_NONBLOCK) = -1 ENOSPC (No space left on device)
>>> [pid 24510] newfstatat(AT_FDCWD, "/dev/pts/1789", 0xffffdd528fe0, 0) = -1 ENOENT (No such file or directory)
>>> [pid 24510] openat(AT_FDCWD, "/dev/ptmx", O_RDWR|O_NOCTTY|O_NONBLOCK) = -1 ENOSPC (No space left on device)
>>> [pid 24510] newfstatat(AT_FDCWD, "/dev/pts/1789", 0xffffdd528fe0, 0) = -1 ENOENT (No such file or directory)
>>> ...
>>>
>>> i'm not sure what can cause such failures, but it happens
>>> regularly on the aarch64 build bot instance recently, let
>>> me know if somebody knows how to make that loop or the
>>> runtime environment more reliable.
>> 
>> I think we should detect that posix_openpt fails and treat ENOSPC,
>> EMFILE, ENFILE as unsupported, along with an error message that we could
>> not create a PTY collision for slavename.  Other error should result in
>> a hard failure.
>> 
>> I can write a patch if you are able to test it.
>
> I agree that's the best option. You should just checkin a fix, it's
> obvious that if we're failing with ENOSPC, EMFILE, or ENFILE that we're
> unable to complete the test.
>
> However, I would add another requirement:
>
> * Print an message indicating possible ways in which this can be fixed
>   to work.
>
> For example, should we try to determine what needs fixing and print an
> appropriate informative message?

I think for the three error codes, the remediative action is implied
(increase the limit).  But how to do that depends on the computing
substrate being used.  I don't think we can provide helpful generic
guidance here.

Thanks,
Florian


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