Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dockerized wdb server doesn't react to SIGTERM #136

Open
yajo opened this issue Nov 18, 2019 · 1 comment
Open

Dockerized wdb server doesn't react to SIGTERM #136

yajo opened this issue Nov 18, 2019 · 1 comment

Comments

@yajo
Copy link
Contributor

yajo commented Nov 18, 2019

I use wdb-server in a docker-compose.yml file, and when stopping services, it's always the latest. I investigated, and it seems it doesn't react to SIGTERM:

Peek 18-11-2019 09-09

yajo added a commit to Tecnativa/doodba-scaffolding that referenced this issue Nov 18, 2019
Nowadays wdb has an official image which is up to date, so there's no need to use my own.

Also I added a workaround for Kozea/wdb#136 to avoid having to wait so long for wdb container to stop. I hope I can revert that part soon.
yajo added a commit to Tecnativa/doodba-scaffolding that referenced this issue Nov 18, 2019
Nowadays wdb has an official image which is up to date, so there's no need to use my own.

Also I added a workaround for Kozea/wdb#136 to avoid having to wait so long for wdb container to stop. I hope I can revert that part soon.
@yajo
Copy link
Contributor Author

yajo commented Aug 6, 2020

I finally found a good workaorund:

  wdb:
    image: kozea/wdb
    # HACK https://github.com/Kozea/wdb/issues/136
    init: true

This avoids the problem of wdb.server.py process stuck when powering off the computer.

yajo pushed a commit to Tecnativa/doodba-copier-template that referenced this issue Aug 6, 2020
Previous hack made it quick to stop the `wdb.server.py` process, which doesn't react properly to `SIGTERM` as explained in Kozea/wdb#136.

However, if this process was still alive, when powering off the computer it took forever to kill it. Thus, using this alternative hack is better, because it uses docker's built-in `tini` to reap child processes. It is still fast, but it also helps the host's process reaper to work reliably.

BTW I update MQT submodule.
yajo pushed a commit to Tecnativa/doodba-copier-template that referenced this issue Aug 11, 2020
Previous hack made it quick to stop the `wdb.server.py` process, which doesn't react properly to `SIGTERM` as explained in Kozea/wdb#136.

However, if this process was still alive, when powering off the computer it took forever to kill it. Thus, using this alternative hack is better, because it uses docker's built-in `tini` to reap child processes. It is still fast, but it also helps the host's process reaper to work reliably.

BTW I update MQT submodule.
github-actions bot pushed a commit to Tecnativa/doodba-copier-template that referenced this issue Aug 11, 2020
Previous hack made it quick to stop the `wdb.server.py` process, which doesn't react properly to `SIGTERM` as explained in Kozea/wdb#136.

However, if this process was still alive, when powering off the computer it took forever to kill it. Thus, using this alternative hack is better, because it uses docker's built-in `tini` to reap child processes. It is still fast, but it also helps the host's process reaper to work reliably.

BTW I update MQT submodule.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant