-
-
Notifications
You must be signed in to change notification settings - Fork 124
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
Resetting hci0 in Docker container is causing zombie processes #157
Comments
Thanks for the bug report - I'll try to reproduce it with my Ubuntu NUC at home. In theory the processes should be hard killed by NodeJS, that was also what I was observing when I tried it. I didn't try it with this specific setup though, so maybe we need some small adaptions in the Dockerfile. |
@mKeRix Awesome, thanks! Let me know if you need any additional info. |
I have the same issue.
Zombie processes
Environment
Config
Room asistant
|
I just tested today using a USB Bluetooth dongle on the NUC and changing the device to |
Agreed. Also the fact, that we all use different dongles/built in chips should theoretically rule out hardware issue per se. |
I also think it's unlikely that this is related to hardware. My current idea is that the hcitool on Alpine Linux (what is used for the Docker images) doesn't handle SIGKILL correctly (or NodeJS doesn't send the signal correctly). As Alpine Linux is rarely used outside of Docker that would explain why we are only seeing the issues there. |
I tried out a Debian image using the following
|
Thanks for checking that already @iicky - saved me some work. I reproduced the issue on a Raspi 3 with Docker today and found a fix. Expect it to be released sometime later today. The issue arose due to the way Docker manages processes, or rather that NodeJS wasn't made to be PID 1. There is some more information in this article. |
# [2.4.0](v2.3.0...v2.4.0) (2020-04-13) ### Bug Fixes * include distances in API for room presence sensors ([567327d](567327d)) * use Tini for process management in Docker ([932d603](932d603)), closes [#157](#157) ### Features * simplify log format ([0f90eaa](0f90eaa)), closes [#170](#170) * **bluetooth-classic:** allow device-specific minRssi values ([cf3ddc5](cf3ddc5)), closes [#168](#168) * **bluetooth-low-energy:** allow the update frequency to be throttled ([0143309](0143309)), closes [#125](#125)
🎉 This issue has been resolved in version 2.4.0 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Perfect - I can confirm that there are no more zombie processes after the update. Thanks so much! |
Same here, works like a charm, fantastic work! Thanks for the fix and the link to give us a bit more background. |
Describe the bug
I am getting a lot of zombie processes popping up as a result of my room-assistant Docker container. It appears as though whenever the BluetoothClassicService query takes too long and
hci0
is reset, it becomes a zombie process. This results in tons of zombie processes over time until I restart the room-assistant container, at which point they all are destroyed.This issue is specifically impacting my deployment on my Intel NUC and is not occurring on my Raspberry Pi deploys.
To reproduce
Deploy using the docker-compose file and config below.
Relevant logs
Room Assistant logs.
Zombie processes.
Relevant configuration
Docker Compose
docker-compose.yaml
Room Assistant config
local.yml
Expected behavior
I expect the zombie processes to not appear.
Environment
Additional context
Zombie processes are not appearing on both Raspberry Pis that have room-assistant installed.
The text was updated successfully, but these errors were encountered: