[v2] tests: fix builds on alpine and centos

Submitted by Adrian Reber on June 21, 2018, 9:10 p.m.

Details

Message ID 1529615438-8899-1-git-send-email-adrian@lisas.de
State Accepted
Series "tests: fix builds on alpine and centos"
Commit c8b3826044e0b592edb6f3036316dc2f474412bf
Headers show

Commit Message

Adrian Reber June 21, 2018, 9:10 p.m.
From: Adrian Reber <areber@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

Signed-off-by: Adrian Reber <areber@redhat.com>
---
 scripts/build/Dockerfile.alpine | 7 ++++++-
 scripts/build/Dockerfile.centos | 1 +
 test/others/rpc/Makefile        | 2 ++
 3 files changed, 9 insertions(+), 1 deletion(-)

Patch hide | download patch | download mbox

diff --git a/scripts/build/Dockerfile.alpine b/scripts/build/Dockerfile.alpine
index a210d06..4163bce 100644
--- a/scripts/build/Dockerfile.alpine
+++ b/scripts/build/Dockerfile.alpine
@@ -4,6 +4,7 @@  ARG ENV1=FOOBAR
 
 RUN apk update && apk add \
 	$CC \
+	bash \
 	build-base \
 	ccache \
 	coreutils \
@@ -15,7 +16,8 @@  RUN apk update && apk add \
 	pkgconfig \
 	protobuf-c-dev \
 	protobuf-dev \
-	python
+	python \
+	sudo
 
 COPY . /criu
 WORKDIR /criu
@@ -37,5 +39,8 @@  RUN apk add \
 	e2fsprogs \
 	asciidoc xmlto
 
+# The rpc test cases are running as user #1000, let's add the user
+RUN adduser -u 1000 -D test
+
 RUN pip install protobuf ipaddress junit_xml
 RUN make -C test/zdtm
diff --git a/scripts/build/Dockerfile.centos b/scripts/build/Dockerfile.centos
index 5f84707..0160b75 100644
--- a/scripts/build/Dockerfile.centos
+++ b/scripts/build/Dockerfile.centos
@@ -27,6 +27,7 @@  RUN yum install -y \
 	python2-junit_xml \
 	python-yaml \
 	python-six \
+	sudo \
 	tar \
 	which \
 	e2fsprogs \
diff --git a/test/others/rpc/Makefile b/test/others/rpc/Makefile
index 5b383cf..2b15873 100644
--- a/test/others/rpc/Makefile
+++ b/test/others/rpc/Makefile
@@ -9,6 +9,8 @@  run: all
 	chmod a+rwx build
 	@# need to start the criu daemon here to access the pidfile
 	sudo -g '#1000' -u '#1000' ./criu service -v4 -W build -o service.log --address criu_service.socket -d --pidfile pidfile
+	# Give the criu daemon some time to start up
+	sleep 0.5
 	chmod a+rw build/pidfile
 	sudo -g '#1000' -u '#1000' ./run.sh
 	sudo -g '#1000' -u '#1000' ./version.py

Comments

Andrey Vagin June 21, 2018, 9:35 p.m.
On Thu, Jun 21, 2018 at 09:10:38PM +0000, Adrian Reber wrote:
> From: Adrian Reber <areber@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.

> 
> Signed-off-by: Adrian Reber <areber@redhat.com>
> ---
>  scripts/build/Dockerfile.alpine | 7 ++++++-
>  scripts/build/Dockerfile.centos | 1 +
>  test/others/rpc/Makefile        | 2 ++
>  3 files changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/scripts/build/Dockerfile.alpine b/scripts/build/Dockerfile.alpine
> index a210d06..4163bce 100644
> --- a/scripts/build/Dockerfile.alpine
> +++ b/scripts/build/Dockerfile.alpine
> @@ -4,6 +4,7 @@ ARG ENV1=FOOBAR
>  
>  RUN apk update && apk add \
>  	$CC \
> +	bash \
>  	build-base \
>  	ccache \
>  	coreutils \
> @@ -15,7 +16,8 @@ RUN apk update && apk add \
>  	pkgconfig \
>  	protobuf-c-dev \
>  	protobuf-dev \
> -	python
> +	python \
> +	sudo
>  
>  COPY . /criu
>  WORKDIR /criu
> @@ -37,5 +39,8 @@ RUN apk add \
>  	e2fsprogs \
>  	asciidoc xmlto
>  
> +# The rpc test cases are running as user #1000, let's add the user
> +RUN adduser -u 1000 -D test
> +
>  RUN pip install protobuf ipaddress junit_xml
>  RUN make -C test/zdtm
> diff --git a/scripts/build/Dockerfile.centos b/scripts/build/Dockerfile.centos
> index 5f84707..0160b75 100644
> --- a/scripts/build/Dockerfile.centos
> +++ b/scripts/build/Dockerfile.centos
> @@ -27,6 +27,7 @@ RUN yum install -y \
>  	python2-junit_xml \
>  	python-yaml \
>  	python-six \
> +	sudo \
>  	tar \
>  	which \
>  	e2fsprogs \
> diff --git a/test/others/rpc/Makefile b/test/others/rpc/Makefile
> index 5b383cf..2b15873 100644
> --- a/test/others/rpc/Makefile
> +++ b/test/others/rpc/Makefile
> @@ -9,6 +9,8 @@ run: all
>  	chmod a+rwx build
>  	@# need to start the criu daemon here to access the pidfile
>  	sudo -g '#1000' -u '#1000' ./criu service -v4 -W build -o service.log --address criu_service.socket -d --pidfile pidfile
> +	# Give the criu daemon some time to start up
> +	sleep 0.5
>  	chmod a+rw build/pidfile
>  	sudo -g '#1000' -u '#1000' ./run.sh
>  	sudo -g '#1000' -u '#1000' ./version.py
> -- 
> 1.8.3.1
>
Adrian Reber June 21, 2018, 9:39 p.m.
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@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.

		Adrian
Adrian Reber June 26, 2018, 6:24 a.m.
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@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.

		Adrian
Andrey Vagin June 26, 2018, 4:37 p.m.
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@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.

> 
> 		Adrian
Adrian Reber June 26, 2018, 5 p.m.
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@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
Dmitry Safonov June 26, 2018, 6:29 p.m.
2018-06-26 18:00 GMT+01:00 Adrian Reber <areber@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@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;
Dmitry Safonov June 26, 2018, 6:43 p.m.
2018-06-26 19:29 GMT+01:00 Dmitry Safonov <0x7f454c46@gmail.com>:
> 2018-06-26 18:00 GMT+01:00 Adrian Reber <areber@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@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 Safonov June 26, 2018, 6:47 p.m.
2018-06-26 19:43 GMT+01:00 Dmitry Safonov <0x7f454c46@gmail.com>:
> 2018-06-26 19:29 GMT+01:00 Dmitry Safonov <0x7f454c46@gmail.com>:
>> 2018-06-26 18:00 GMT+01:00 Adrian Reber <areber@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@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.

JFI:
it looks like, bash folks says they fixed it somehow:
https://lists.gnu.org/archive/html/bug-bash/2017-07/msg00039.html

So, probably, you've got a newer version on Alpine.
Adrian Reber June 26, 2018, 9:09 p.m.
On Tue, Jun 26, 2018 at 07:47:22PM +0100, Dmitry Safonov wrote:
> 2018-06-26 19:43 GMT+01:00 Dmitry Safonov <0x7f454c46@gmail.com>:
> > 2018-06-26 19:29 GMT+01:00 Dmitry Safonov <0x7f454c46@gmail.com>:
> >> 2018-06-26 18:00 GMT+01:00 Adrian Reber <areber@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@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.
> 
> JFI:
> it looks like, bash folks says they fixed it somehow:
> https://lists.gnu.org/archive/html/bug-bash/2017-07/msg00039.html
> 
> So, probably, you've got a newer version on Alpine.

Thanks for finding this. This seems to be the problem I am seeing.

Unfortunately it does not really help as we depend on the version of
bash in the Ubuntu travis image. At least I do not know how to install a
newer version of bash to fix it. And writing another character than \0
to the status_fd would also work, but CRIU already defined \0 as the
character it is writing. So this is also difficult to change.

This is really unfortunate and I am not sure how to correctly fix it. I
could temporarily patch CRIU to write something else during the test,
but this seems like the wrong approach.

Any other ideas how check if CRIU wrote something to the status fd?

Using python to read it seems to work:

bash -c 'rm -f status; mkfifo status; exec 201<>status; ./a.out 201; python -c "import os; f=open(\"status\") ; f.read(1); "'

But this looks really like overkill for a test case. I will try to get
it verified by travis on all test targets, if no one has a better idea.

		Adrian
Andrey Vagin June 28, 2018, 7:30 a.m.
On Tue, Jun 26, 2018 at 07:00:47PM +0200, Adrian Reber wrote:
> 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@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'
> 


bash -c 'rm -f status; mkfifo status; exec 200<>status; exec 201>status; exec 202<status; exec 200<&-; strace ./a.out 201; exec 201<&-; cat <&202 | hexdump' 

I think this version will work.

> 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
Adrian Reber June 28, 2018, 7:55 a.m.
On Thu, Jun 28, 2018 at 12:30:17AM -0700, Andrei Vagin wrote:
> On Tue, Jun 26, 2018 at 07:00:47PM +0200, Adrian Reber wrote:
> > 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'
> > 
> 
> bash -c 'rm -f status; mkfifo status; exec 200<>status; exec 201>status; exec 202<status; exec 200<&-; strace ./a.out 201; exec 201<&-; cat <&202 | hexdump' 
> 
> I think this version will work.

I don't understand it but it looks cool ;) Thanks for your help, but I
already have a solution using a python script to read from the
status_fd. I am currently waiting on the last travis run and will post
the patches later.

		Adrian