[CRIU] [PATCH v2] tests: fix builds on alpine and centos

[Dmitry Safonov]

2018-06-26 19:29 GMT+01:00 Dmitry Safonov <0x7f454c46 at gmail.com>:
> 2018-06-26 18:00 GMT+01:00 Adrian Reber <areber at redhat.com>:
>> On Tue, Jun 26, 2018 at 09:37:08AM -0700, Andrei Vagin wrote:
>>> On Tue, Jun 26, 2018 at 08:24:08AM +0200, Adrian Reber wrote:
>>> > On Thu, Jun 21, 2018 at 11:39:19PM +0200, Adrian Reber wrote:
>>> > > On Thu, Jun 21, 2018 at 02:35:38PM -0700, Andrei Vagin wrote:
>>> > > > On Thu, Jun 21, 2018 at 09:10:38PM +0000, Adrian Reber wrote:
>>> > > > > From: Adrian Reber <areber at redhat.com>
>>> > > > >
>>> > > > > Install sudo, create test user with ID 1000, install bash,
>>> > > > > fix pidfile creation and pidfile chmod.
>>> > > > >
>>> > > > > v2:
>>> > > > >  * use sleep to give the criu daemon some time to start up
>>> > > >
>>> > > > Can we use --status-fd? It is designed for this.
>>> > >
>>> > > Oh, very good idea. Thanks. I will try that.
>>> >
>>> > Just to let you know. I have problems reading the result from the
>>> > status_fd on all our different travis targets. It works for most shells,
>>> > but not all of them. Still trying to understand how to correctly solve
>>> > this, so that it works everywhere.
>>>
>>> We already install bash in all docker containers, so you can create a
>>> bash script.
>>
>> I currently have the problem that 'read -n 1' hangs on Ubuntu and it is
>> not clear why. I have the following test case:
>>
>> bash -c 'rm -f status; mkfifo status; exec 201<>status;  ./a.out 201; read -n1 -u 201'
>>
>> The test program a.out (great name) is really simple:
>>
>> #include <stdio.h>
>> #include <stdlib.h>
>>
>> int main(int argc, char *argv[])
>> {
>>         int status_fd;
>>         char c = 0;
>>         int r;
>>
>>         status_fd = atoi(argv[1]);
>>
>>         printf("status_fd %d\n", status_fd);
>>         r = write(status_fd, &c, 1);
>>         printf("write %d\n", r);
>> }
>>
>> And strace tells me the following:
>>
>> fcntl(201, F_GETFD)                     = 0
>> ioctl(201, TCGETS, 0x7ffd97626ad0)      = -1 ENOTTY (Inappropriate ioctl for device)
>> lseek(201, 0, SEEK_CUR)                 = -1 ESPIPE (Illegal seek)
>> read(201, "\0", 1)                      = 1
>> read(201,
>>
>> On CentOS and alpine it does not hang and I get the following:
>>
>> fcntl(201, F_GETFD)                     = 0
>> ioctl(201, TCGETS, 0x7ffeeb6ee6a0)      = -1 ENOTTY (Inappropriate ioctl for device)
>> lseek(201, 0, SEEK_CUR)                 = -1 ESPIPE (Illegal seek)
>> read(201, "\0", 1)                      = 1
>> exit_group(0)                           = ?
>>
>> So on Ubuntu, for some reason, 'read -n 1' does not stop after reading a
>> single byte from the pipe and that seems to be the problem I have in
>> travis.
>>
>> Can you reproduce this behavior? Do you have an idea why this is
>> happening? I am doing something wrong? I am already looking at the code
>> for a few days and it is not clear what is happening here.
>
> It looks like, `read' bash command doesn't count zero-bytes with -n.
>
>> char c = 0;

IOW,
bash -c 'read a -n1 < /dev/zero'
hangs for me indefinetely.

-- 
             Dmitry