I had been adding --env SHELL=/bin/bash to the x11docker invocation and then I noticed that most interactive commands in the terminal are not responding to suspend (Control-Z), and so that means when I run sleep 100 then type Control-Z then there is no effect. Control-C however works. I checked stty -a and this shows normal settings for susp. I even built completely minimal Alpine and Devuan images that only add stterm and bash and these problems only seem to show themselves when SHELL is set to bash. I tried not including the --env to begin with, setting it to zsh, setting it to dash and those all worked fine.

Then I tried running SHELL=/bin/bash st within the invoked x11docker container (with --env SHELL=/bin/bash) and interactive suspend didn't work. I then ran SHELL=/bin/dash st and in the subsequent spawned window ran SHELL=/bin/bash st and in those final two windows (even in the very final one in which SHELL is bash), suspend did work. Of course I could try a lot of strange permutations to attempt to hone in on what works and what doesn't, but because stty -a output looks as though susp is assigned to Control-Z just as always, I don't really know what the root cause is when this is manifesting. xev would just show correctly processed keypresses, and I would ordinarily turn to stty -a as the source of truth. Without involving x11docker, a command like SHELL=/bin/bash st works without an issue.

A command that has its own "handler" for Control-Z (like less I believe) will at least process a suspend request but that may only come up because of custom code for that command; in general the signal doesn't seem to be getting passed in the shell, specifically when there are conditions that look like SHELL being bash at invocation of x11docker. I don't know if the suspend event is somehow making its way elsewhere, like to init, or if it's being masked, or if some setup scripts are doing different things conditionally if the shell is bash. Pressing a Control-V Control-Z sequence reveals "^Z" is added in the working command line, so it's not as though Control-Z isn't being seen.

I'm mentioning this here because it seems pretty confusing and anomalous and maybe something can be addressed that could help prevent further unexpected issues. In my case I'm using --nxagent (and also a non --desktop mode with just st as a command), although I'm hoping this is easily reproducible, especially since my containers were built so minimally from the base images and also because I tried a variety of permutations.