Does `strace -f` work differently when run inside a docker container?

Assume the following:

I have a program myprogram inside a docker container
I'm running the docker container with

docker run --privileged=true my-label/my-container
Inside the container - the program is being run with:

strace -f -e trace=desc ./myprogram

What I see is that the strace (despite having the -f on) doesn't follow all the child processes.

I see the following output from strace

[pid    10] 07:36:46.668931 write(2, "..\n"..., 454 <unfinished ...>

<stdout of ..>

<stdout other output - but I don't see the write commands - so probably from a child process>

[pid    10] 07:36:46.669684 write(2, "My final output\n", 24 <unfinished ...>

<stdout of My final output>

What I want to see is the other write commands.

Now I should see the the other write commands - because I'm using -f.

What I think is happening is that running inside docker makes the process handling and security different.

My question is: Does strace -f work differently when run inside a docker container?

Note that this application starts and stops in 2 seconds - so the tracing tool has to follow the application lifecycle - like strace does. Connecting to a server background process won't work.

Solution

It turns out strace truncates string output - you have to explicitly tell it that you want more than the first n (10?) string chars. You do this with -s 800.

strace -s 800 -ff  ./myprogram

You can also get all the write commands by asking strace explicitly with -e write.

strace -s 800 -ff -e write  ./myprogram