2015-08-25 11:01 GMT-03:00 Laurent Bercot: > > I can't reproduce that one, can you please send me a "strace -vf -s 256" > output of the s6-rc command that gives you these errors ?
OK, this is a tricky one. While looking at the strace output you asked for, I realized myself what was going on. The s6-svc process 's6-rc change' is spawning has options '-uwu -T 3', and my test system seems to be slow enough (don't ask :) ) that it turns out a 3 millisecond timeout is too small. A manual s6-svc invocation with that timeout produces the same errors I saw when using s6-rc. And trying different -T options, it takes over 30 ms to actually start the service I was performing the tests with, and over 70 ms to do so without s6-svlisten1 error messages. All my previous manual s6-svc invocations didn't specify a timeout, so I didn't notice until now. But the thing is, no matter what I do, strace shows the '-T 3' never changes. Even when I explicitly put a 'timeout-up' file in the service definition directory, either containing '0' or a long enough timeout, or when I give s6-rc change a -t option. 's6-rc-db timeout' does show the timeout specified by me, and correctly shows 0 when there is no 'timeout-up' file. So the real issue here appears to be that s6-svc is always told to wait no longer than 3 ms, and, in particular, you would't be able to make s6-rc wait forever in the "no readiness notification" case. Thanks, G.
