fix(libcontainer):enhance the detail of error printing

[jokemanfire]

While I meet some exec fifo's problem , Not friendly enough for my positioning problem. So I want more detailed printing.

it will be like this
ERRO[0016] containerd: start init process error="exit status 1: "start for 13179ebcb85b085b588613c99c154405148eb552b4565d0e6268d6ba242d015a failed: container process is already dead,because openResult err: container_linux.go:275: open exec fifo for reading caused \"open /run/runc/13179ebcb85b085b588613c99c154405148eb552b4565d0e6268d6ba242d015a/exec.fifo: no such file or directory\"\none or more of container start failed\n""

I have identified this issue and may initiate a discussion in the future.

[kolyshkin]

I doubt it adds any value. Container's dead is container's dead, adding more details just makes it more confusing for users.

[jokemanfire]

I doubt it adds any value. Container's dead is container's dead, adding more details just makes it more confusing for users.

I don't think it will increase user confusion, as the operating user still knows how to exit the container (just in more detail). On the contrary, if these prints are not added, it will increase the confusion for developers, especially when I encountered this problem in my business scenario. However, I have no idea what caused the container to die, which increases the difficulty of post positioning.

[rata]

@jokemanfire can you post how the error was shown before too?

I'm not against, if it adds clarity and helps to debug something. But it's not clear adding that will help

[jokemanfire]

container process is already dead

The question's backgroud are as follows :
1.I use docker run to run a contianer. But I meet this problem
container process is already dead, it makes me confuse.
2.After investigation, I have reproduced this problem,
At that time, a scan or other operation may have been performed, resulting in the pre reading of exec.fifo. And I open this disscussion #4795
3. If there is this print, I can clearly know that a process has read exec.fifo due to errors such as read failure, file non existence, file deletion failure, etc. Instead of the confusing container process being already dead.

[rata]

Okay, looking at the PR and the error, I can see what was shown before. Looking at the discussion, it seems this happens if you are running a grep -R in a location that happens to include the fifo file?

Can you explain in more detail how the bug can happen (even if it's hard to repro)? Because the error you are showing is that the fifo file doesn't exist, it's not clear from the description how the file is being deleted.

Am I missing something?

[rata]

You will need to sing-off the commit, as the CI is failing for that

[jokemanfire]

Okay, looking at the PR and the error, I can see what was shown before. Looking at the discussion, it seems this happens if you are running a grep -R in a location that happens to include the fifo file?

Can you explain in more detail how the bug can happen (even if it's hard to repro)? Because the error you are showing is that the fifo file doesn't exist, it's not clear from the description how the file is being deleted.

Am I missing something?

Sorry for late replay , it should because that exec.fifo which created by 'runc init', and it has been read by other process which is not the 'runc start', so 'runc init' process continue with the remaining operations, and delete the exec.fifo , so docker continue with the remaining operations, so print this error.

[kolyshkin]

I think this one can be closed. It is of some help to someone who's looking into how runc works, but for most users this will be a downgrade -- they don't want to know any internal details about how runc detects this and that, they want a simple message.

IOW current error message is fine.