Resetting hci0 in Docker container is causing zombie processes
See original GitHub issueDescribe 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.
docker logs -f room-assistant
[Nest] 1 - 03/22/2020, 11:44:54 AM [BluetoothClassicService] Query of xx:xx:xx:xx:xx:xx took too long, resetting hci0
[Nest] 1 - 03/22/2020, 11:46:24 AM [BluetoothClassicService] Query of xx:xx:xx:xx:xx:xx took too long, resetting hci0
[Nest] 1 - 03/22/2020, 11:46:35 AM [BluetoothClassicService] Query of xx:xx:xx:xx:xx:xx took too long, resetting hci0
[Nest] 1 - 03/22/2020, 11:46:36 AM [BluetoothClassicService] Query of xx:xx:xx:xx:xx:xx took too long, resetting hci0
[Nest] 1 - 03/22/2020, 11:55:06 AM [BluetoothClassicService] Query of xx:xx:xx:xx:xx:xx took too long, resetting hci0
Zombie processes.
user@core:~$ ps auxwww | grep ' Z '
4 Z root 5859 28012 0 80 0 - 0 - 13:44 ? 00:00:00 [hcitool] <defunct>
4 Z root 7486 28012 0 80 0 - 0 - 13:46 ? 00:00:00 [hcitool] <defunct>
4 Z root 7672 28012 0 80 0 - 0 - 13:46 ? 00:00:00 [hcitool] <defunct>
4 Z root 7713 28012 0 80 0 - 0 - 13:46 ? 00:00:00 [hcitool] <defunct>
Relevant configuration
Docker Compose docker-compose.yaml
version: "3.1"
services:
# Room Assistant-----------------------------------
room-assistant:
container_name: room-assistant
image: mkerix/room-assistant
network_mode: host
ports:
- 6425:6425
cap_add:
- NET_ADMIN
volumes:
- /var/run/dbus:/var/run/dbus
- ./room-assistant/config:/room-assistant/config
- /etc/localtime:/etc/localtime:ro
restart: always
Room Assistant config local.yml
global:
instanceName: office
integrations:
- homeAssistant
- bluetoothClassic
homeAssistant:
mqttUrl: 'mqtt://XXX.XXX.XXX.XXX:1883'
mqttOptions:
username: <username>
password: <password>
cluster:
networkInterface: eno1
port: 6425
peerAddresses:
- <raspberry_pi_zero_1>:6425
- <raspberry_pi_zero_1>:6425
bluetoothClassic:
addresses:
- '<mac_address_1>'
- '<mac_address_2>'
Expected behavior I expect the zombie processes to not appear.
Environment
- room-assistant version: 2.1.1
- installation type: Docker
- hardware: Intel NUC8i5BEK1
- OS: Ubuntu 18.04.4 LTS (GNU/Linux 4.15.0-91-generic x86_64)
Additional context
Zombie processes are not appearing on both Raspberry Pis that have room-assistant installed.
Issue Analytics
- State:
- Created 3 years ago
- Comments:11 (3 by maintainers)
Top GitHub Comments
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.
I tried out a Debian image using the following
Dockerfile
and I am still getting the same zombie processes. I did my best to find matching or similar packages so I’m not 100% sure the image is a complete Debian replacement, but I can confirm that the zombie processes are still appearing with Debian.