dumb-init: Error: cannot set terminal process group (-1): Inappropriate ioctl for device

When I have dumb-init in ENTRYPOINT like this

...
ENTRYPOINT ["/usr/bin/dumb-init"]
...

and then try to run bash with tty and interactively, I get this error:

docker run --rm -t -i dumb_init_image bash
bash: cannot set terminal process group (-1): Inappropriate ioctl for device
...

About this issue

  • Original URL
  • State: closed
  • Created 8 years ago
  • Reactions: 6
  • Comments: 15 (7 by maintainers)

Commits related to this issue

Most upvoted comments

Unfortunately I still see this error message, using dumb-init 1.2.0 (Ubuntu 16.04, both directly in the host shell, and inside a docker run --rm -ti ubuntu:16.04 bash):

$ ./dumb-init_1.2.0_amd64 bash
bash: cannot set terminal process group (-1): Inappropriate ioctl for device
bash: no job control in this shell
$ exit
$ ./dumb-init_1.2.0_amd64 -c bash
$ exit

Note that tini does not exhibit this problem (i.e. works fine with and without its -g flag).

@alhafoudh still looking into the root cause. I think it’s something we can fix.

For now a workaround is to run in non-setsid mode using -c, e.g.

ENTRYPOINT ["/usr/bin/dumb-init", "-c", "--"]

The only difference behavior-wise is that signals are only forwarded to your direct child. So if you have a process tree like

PID 1: dumb-init
+---- PID 2: python server
    +---- PID 3: worker process
    +---- PID 4: worker process
    +---- PID 5: worker process

when you send docker signal, the signal is only delivered to PID 2 and not everything in the process group (potentially including the workers).

This is usually acceptable behavior since the server is supposed to handle signaling its workers before it dies anyway. Unfortunately there are some exceptions, which is why the default is setsid mode.

I’ll keep looking into this and get back to you.

@alhafoudh thanks for the issue! I was able to reproduce it, we’ll look into it.

Just to confirm, are you still getting a usable shell? (I’m getting the error printed, but still get a shell afterwards. Just want to confirm the behavior is the same for you.)

@ehlers perhaps open a PR for hacktoberfest? 😃

@athakwani, @ehlers, thanks a lot for both the patch and the bump!

I just tried the patch out locally and it seems to be working great (all the existing tests pass, and we do test the behavior we care about pretty extensively).

I was a little concerned about what effect it would have on the new --rewrite flag that was added, but it appears to work with no additional changes.

I’ll spend a little more time looking into what exactly this is doing, but I’ll plan to write a test for this new behavior and make a PR shortly.