support to print stack

[ningmingxiao]

Signed-off-by: ningmingxiao ning.mingxiao@zte.com.cn
sometimes runc is hanged ,this will show where hang

[ningmingxiao]

but after unix.Close(l.logFd) at standard_init_linux.go , I can't use logrus to print stack, this will miss some messages @kolyshkin

[kolyshkin]

but after unix.Close(l.logFd) at standard_init_linux.go , I can't use logrus to print stack, this will miss some messages @kolyshkin

Yes, since the logs are being forwarded to the parent, the parent has to live until there are logs. Previously (before #2835) sometimes the parent was exiting prematurely, resulting in some logs being lost. Now, we do wait for the child to close the log fd, to make sure all the logs are forwarded.

All it means for this case is it's not possible to use logrus from runc init after closing the logs. I am not sure how to handle this, perhaps the bold approach would be to remove logs forwarding goroutine entirely, instead passing the logrus fd directly to init. This needs some thinking and experimenting though

[kolyshkin]

the bold approach would be to remove logs forwarding goroutine entirely, instead passing the logrus fd directly to init.

This might work, but we need to teach the C code to work the same way as logrus -- meaning, produce either text or json, depending on settings and whether fd is a terminal.

[ningmingxiao]

the bold approach would be to remove logs forwarding goroutine entirely

I don't understand "the bold approach would be to remove logs forwarding goroutine entirely" can you explain it ?

[kolyshkin]

I don't understand "the bold approach would be to remove logs forwarding goroutine entirely" can you explain it ?

For runc init, we use a goroutine that receives log entries from the C code in libcontainer/nsenter and sends them to logrus (see ForwardLogs in libcontainer/logs).

In theory, we can remove this log forwarding, instead passing the log file descriptor to C code, and log directly from there.