Striker/Horizon are running in Blubber built containers with a runtime UID that does not exist on the host machine
Open, Needs TriagePublic
Actions

Assigned To

None

Authored By

	MoritzMuehlenhoff
	Thu, Apr 25, 9:43 AM

Description

debdeploy failed to resolve some missing restarts on cloudweb and digging a little deeper it seems we're running some services (Striker, Horizon, not sure if the Apache processes relate to something else) with a non-existing UID:

jmm@cloudweb1004:~$ grep 900 /etc/passwd
jmm@cloudweb1004:~$
jmm@cloudweb1004:~$ ps aux | grep 900
root        1397  0.1  0.1 4269004 142836 ?      Ssl  Feb19 172:22 /usr/sbin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
900       273213  0.0  0.0   2480   516 ?        Ss   Mar19   0:00 /bin/sh /srv/app/entrypoint.sh 0.0.0.0:8084
900       273227  0.0  0.0  13368  6336 ?        S    Mar19   2:32 /usr/sbin/apache2 -d /srv/app -f /srv/app/apache2.conf -DFOREGROUND -k start
900       273229  0.0  0.5 1358796 743424 ?      Sl   Mar19  11:26 horizon           -d /srv/app -f /srv/app/apache2.conf -DFOREGROUND -k start
900       273230  0.0  0.5 1313840 765152 ?      Sl   Mar19  12:22 horizon           -d /srv/app -f /srv/app/apache2.conf -DFOREGROUND -k start
900       273231  0.0  0.5 1165476 694000 ?      Sl   Mar19  11:46 horizon           -d /srv/app -f /srv/app/apache2.conf -DFOREGROUND -k start
900       273232  0.0  0.0 2008220 21052 ?       Sl   Mar19   0:04 /usr/sbin/apache2 -d /srv/app -f /srv/app/apache2.conf -DFOREGROUND -k start
900       273233  0.0  0.0 1943020 21344 ?       Sl   Mar19   0:05 /usr/sbin/apache2 -d /srv/app -f /srv/app/apache2.conf -DFOREGROUND -k start
900       273234  0.0  0.0 2008124 20988 ?       Sl   Mar19   0:03 /usr/sbin/apache2 -d /srv/app -f /srv/app/apache2.conf -DFOREGROUND -k start
900       278249  0.0  0.0 2008500 21376 ?       Sl   Mar19   0:11 /usr/sbin/apache2 -d /srv/app -f /srv/app/apache2.conf -DFOREGROUND -k start
900      1100616  0.3  0.2 7441216 366272 ?      Ssl  Apr12  65:12 /opt/lib/poetry/striker-2uZo5AhP-py3.11/bin/python3 manage.py runserver --noreload --nostatic 0.0.0.0:8080
900      1148957  0.0  0.0 1446412 108500 ?      Ss   Apr18   1:07 /opt/lib/poetry/striker-2uZo5AhP-py3.11/bin/python3 manage.py runserver --noreload --nostatic 0.0.0.0:8081

Event Timeline

MoritzMuehlenhoff created this task.Thu, Apr 25, 9:43 AM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptThu, Apr 25, 9:43 AM

Those are running in containers, and the user does exist in the container:

taavi@cloudweb1004 ~ $ sudo docker exec -it striker.service id 900
uid=900(runuser) gid=900(runuser) groups=900(runuser)

Is debdeploy not handling that correctly?

bd808 renamed this task from Striker/Horizon are running with a non-existing user to Striker/Horizon are running in Blubber built containers with a runtime UID that does not exist on the host machine.Thu, Apr 25, 8:52 PM

In T363452#9744332, @taavi wrote:

Those are running in containers, and the user does exist in the container:

Ack. If the UID is fixed within the container, it makes sense to also register it on the host via systemd::sysuser or similar. But I'm also fine with just closing the task.

Is debdeploy not handling that correctly?

lsof (which is used by debdeploy) stumbles over it, but I'll add a patch to debdeploy to handle this gracefully, since we might run into this in other cases as well.

Striker/Horizon are running in Blubber built containers with a runtime UID that does not exist on the host machineOpen, Needs TriagePublicActions

Description

Event Timeline

Striker/Horizon are running in Blubber built containers with a runtime UID that does not exist on the host machine
Open, Needs TriagePublic
Actions