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

[Adrian Reber]

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.

		Adrian