<div dir="ltr"><div>Hello!</div><div><br></div>Thanks for the quick response and for the hint! After testing with <span style="font-size:12.8px">-fveseccomp,prctl it turns out that:</span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">docker-engine 1.10.1-0~wily uses seccomp (prctl </span><span style="color:rgb(0,0,0);font-family:monospace">PR_SET_SECCOMP, SECCOMP_MODE_FILTER and </span><span style="color:rgb(0,0,0);font-family:monospace">PR_CAPBSET_DROP ...)</span><span style="font-size:12.8px">, whereas 1.10.1-0~jessie doesn't. Though eventually by default Docker will filter out (almost all?) syscalls: <a href="https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities">https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities</a> </span></div><div><br></div><div>Cheers,</div><div><div><div><span style="font-size:12.8px">Pas</span></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Feb 13, 2016 at 5:24 AM, Dmitry V. Levin <span dir="ltr"><<a href="mailto:ldv@altlinux.org" target="_blank">ldv@altlinux.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<div><div class="h5"><br>
On Sat, Feb 13, 2016 at 04:05:50AM +0100, Pas wrote:<br>
> Hello!<br>
><br>
> I would like to ask for a bit of help and maybe report a bug (but it's<br>
> probably just a known, however, a rather confusing behavior of strace).<br>
><br>
> While running serf (a Raft consensus agent) in Docker (which uses cgroups<br>
> and kernel namespaces) I got a strange error. ("==> Failed to start the<br>
> Serf agent: Error creating Serf: Failed to create memberlist: Failed to<br>
> start TCP listener. Err: listen tcp <a href="http://0.0.0.0:7946" rel="noreferrer" target="_blank">0.0.0.0:7946</a>: socket: operation not<br>
> permitted") But the process inside the container should be behaving as a<br>
> process running as root, with all the necessary capabilities.<br>
><br>
> So, strace-ing from the host (cannot strace/ptrace from the container<br>
> without using --privileged), I get the following trace:<br>
><br>
> ...<br>
> [pid 17148] read(3,  <unfinished ...><br>
> [pid 17144] clock_gettime(CLOCK_MONOTONIC,  <unfinished ...><br>
> [pid 17148] <... read resumed> "", 4096) = 0<br>
> [pid 17144] <... clock_gettime resumed> {939382190280542405,<br>
> 579195224836800512}) = 0<br>
> [pid 17148] close(3 <unfinished ...><br>
> [pid 17144] clock_gettime(CLOCK_REALTIME,  <unfinished ...><br>
> [pid 17148] <... close resumed> )       = 0<br>
> [pid 17144] <... clock_gettime resumed> {4155469542819979293, 17314723865})<br>
> = 0<br>
> [pid 17148] clock_gettime(CLOCK_REALTIME,  <unfinished ...><br>
> [pid 17144] _newselect(0, NULL, NULL, NULL, {85899345920, 86034069969}<br>
> <unfinished ...><br>
> [pid 17148] <... clock_gettime resumed> {4155579120320602141,<br>
> 598189438530486336}) = 0<br>
> [pid 17148] futex(0x18928620, FUTEX_WAKE, 1) = 1<br>
> [pid 17146] <... futex resumed> )       = 0<br>
> [pid 17146] _newselect(0, NULL, NULL, NULL, {429496729600, 429631460482}<br>
> <unfinished ...><br>
> [pid 17144] <... _newselect resumed> )  = 0 (Timeout)<br>
> [pid 17144] clock_gettime(CLOCK_MONOTONIC, {940046419857770693,<br>
> 579195224836800512}) = 0<br>
> [pid 17144] clock_gettime(CLOCK_REALTIME,  <unfinished ...><br>
> [pid 17148] syscall_4294967295(0x1, 0x18935730, 0, 0, 0, 0xff <unfinished<br>
> ...><br>
> [pid 17144] <... clock_gettime resumed> {4156106598139125789, 17314723865})<br>
> = 0<br>
> [pid 17148] <... syscall_4294967295 resumed> ) = -1 (errno 1)<br>
<br>
</div></div>4294967295 is (unsigned int) -1.<br>
Looks like a side effect from a seccomp filter that messes up with<br>
syscalls.  Try strace -fveseccomp,prctl to check this hypothesis.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
ldv<br>
</font></span></blockquote></div><br></div>