Odd behaviour in container with AutoInterface

[deavmi]

Interesting thing I noticed. Previously I was able to containerize and instance of rnsd with an AutoInterface enabled, but now it seems to cause a crash on startup of the container.

Problem is that I have logging set to as high as possible but Docker shows no logs when the failure occurs at all. Just that the process rnsd exited with 255 exit code (and sometimes with 0).

It's odd as I had this working perfectly a few versions back I think, but even changing that doesn't seem to help. I have tested it on different Docker hosts and it seems only the original one I tested it on still works - other than that a little lost. But this may have been a case of a slow Docker host that just "made it work" by chance.

Any advice of how I could maybe try get some more debugging information out of this? I know for a fact that if I run some other CMD for the container and then docker exec into the container and start rnsd there then it seems to work. --- This leads me to think maybe something isn't fully initialised prior to rnsd starting (maybe container network interfaces or something) - as now and then (infrequently) the container will launch correctly.

[deavmi]

This probaby is some Docker problem, or rnsd. I'm unsure. What I am trying now is inserting a 5 second sleep on container start and then starting rnsd....

Will see how this goes...

[deavmi]

Interesting, that seems to do the job. I wonder though, it does feel like something that should be handled.

I'll give the code a look to see what I can find. It must be some call being made in AutoInterface, probably relating to enumerating the interfaces or something that crashes.

[markqvist]

Thanks @deavmi! Looking forward to hearing what you find.

[skyguy]

I had a problem seeing logs while trying to run under systemd, which turned out to be buffering of the logs. See my PR #698

-Kevin

[deavmi]

I had a problem seeing logs while trying to run under systemd, which turned out to be buffering of the logs. See my PR #698

-Kevin

If this makes it into a new release then I can re-test my stuff and remove my sleep 5 so as to get to the actual problem.

Would it work for Docker? As Docker provides stdout fd as to capture logs, what check are you usng to see the underlying file/device being written to in order to determine what logging environment is being used?