[SOLVED] OCI LXC Probleme beim Starten

A

AlexHuebi

New Member
Oct 22, 2025
3
0
1
Grüß euch!

Nachdem ich vor ein paar Monaten bereits erfolgreich einen OCI Container in PVE zum testen importierte, dachte ich mir, dass es wohl auch dieses mal Funktionieren würde, aber möglicherweise gibt es doch noch ein paar Probleme die behoben müssen oder ich habe beim Initialen Setup etwas falsch gemacht.

Und zwar wollte ich den soundcork-stockholm-app Container aus der ghcr starten - ghcr.io/krahl/soundcork-stockholm-app:latest, Sourcecode liegt bei https://github.com/krahl/soundcork-stockholm-app
Import und erstellen des Containers verlief soweit ohne Probleme, ich habe auch die notwendigen Volumes gemounted, jedoch wenn ich nun den Container starten will, bekomme ich in der UI nur den folgenden Fehler:
Code: 
lxc-info: 5006: ../src/lxc/af_unix.c: lxc_abstract_unix_recv_fds_iov: 218 Connection reset by peer - Failed to receive response
lxc-info: 5006: ../src/lxc/commands.c: lxc_cmd_rsp_recv_fds: 128 Failed to receive file descriptors for command "get_init_pid"
TASK ERROR: unable to get PID for CT 5006 (not running?)


Einen Blick ins Journal liefert mir leider keine wirkliche Antwort:
Code: 
May 14 21:47:36 pve pvedaemon[2933]: starting 1 worker(s)
May 14 21:47:36 pve pvedaemon[2933]: worker 574346 started
May 14 21:51:51 pve pvedaemon[574346]: <root@pam> starting task UPID:pve:0008D292:003A51AE:6A0627D7:vzstart:5006:root@pam:
May 14 21:51:51 pve pvedaemon[578194]: starting CT 5006: UPID:pve:0008D292:003A51AE:6A0627D7:vzstart:5006:root@pam:
May 14 21:51:51 pve systemd[1]: Started pve-container@5006.service - PVE LXC Container: 5006.
May 14 21:51:52 pve dbus-daemon[2242]: [system] Activating via systemd: service name='org.freedesktop.timedate1' unit='dbus-org.freedesktop.timedate1.service' requested by ':1.55' (uid=0 pid=578215 comm="timedatectl show --property=Timezone --value" label="/usr/bin/lxc-start (enforce)")
May 14 21:51:52 pve systemd[1]: Starting systemd-timedated.service - Time & Date Service...
May 14 21:51:52 pve systemd[1]: Started systemd-timedated.service - Time & Date Service.
May 14 21:51:52 pve dbus-daemon[2242]: [system] Successfully activated service 'org.freedesktop.timedate1'
May 14 21:51:52 pve kernel: audit: type=1400 audit(1778788312.184:138): apparmor="STATUS" operation="profile_load" profile="/usr/bin/lxc-start" name="lxc-5006_</var/lib/lxc>" pid=578223 comm="apparmor_parser"
May 14 21:51:52 pve kernel: vmbr050: port 26(veth5006i0) entered blocking state
May 14 21:51:52 pve kernel: vmbr050: port 26(veth5006i0) entered disabled state
May 14 21:51:52 pve kernel: veth5006i0: entered allmulticast mode
May 14 21:51:52 pve kernel: veth5006i0: entered promiscuous mode
May 14 21:51:52 pve kernel: eth0: renamed from vethCtwtkM
May 14 21:51:52 pve kernel: vmbr050: port 26(veth5006i0) entered disabled state
May 14 21:51:52 pve kernel: veth5006i0 (unregistering): left allmulticast mode
May 14 21:51:52 pve kernel: veth5006i0 (unregistering): left promiscuous mode
May 14 21:51:52 pve kernel: vmbr050: port 26(veth5006i0) entered disabled state
May 14 21:51:52 pve pvedaemon[570260]: Use of uninitialized value in subtraction (-) at /usr/share/perl5/PVE/LXC.pm line 339.
May 14 21:51:52 pve pvestatd[2930]: Use of uninitialized value in subtraction (-) at /usr/share/perl5/PVE/LXC.pm line 339.
May 14 21:51:52 pve kernel: audit: type=1400 audit(1778788312.739:139): apparmor="STATUS" operation="profile_remove" profile="/usr/bin/lxc-start" name="lxc-5006_</var/lib/lxc>" pid=578360 comm="apparmor_parser"
May 14 21:51:52 pve pvestatd[2930]: lxc status update error: failed to read from command socket: Connection reset by peer
May 14 21:51:52 pve pvedaemon[578194]: unable to get PID for CT 5006 (not running?)
May 14 21:51:52 pve pvedaemon[574346]: <root@pam> end task UPID:pve:0008D292:003A51AE:6A0627D7:vzstart:5006:root@pam: unable to get PID for CT 5006 (not running?)
May 14 21:51:53 pve systemd[1]: pve-container@5006.service: Deactivated successfully.
May 14 21:51:53 pve systemd[1]: pve-container@5006.service: Consumed 462ms CPU time, 90.8M memory peak.

Testweise habe ich auch noch einen anderen Container importiert, jc21/nginx-proxy-manager:2.14.0 , welcher ohne direkt beim ersten Versuch startete und auch erreichbar ist.

Ist das Problem irgendwie meinerseits lösbar oder wird hier einen Patch seitens Proxmox notwendig werden?
 
Hi!

Bitte poste noch den Output von den folgenden Kommandos:

Code: 
$ pveversion -v
$ pct config 5006
$ pct start 5006 --debug
 
Hi,
folgend ist der Output der Konsole:
Code: 
root@pve:~# pveversion -v
proxmox-ve: 9.1.0 (running kernel: 7.0.2-2-pve)
pve-manager: 9.1.11 (running version: 9.1.11/8eac2c86f015bdda)
proxmox-kernel-helper: 9.0.4
proxmox-kernel-7.0: 7.0.2-2
proxmox-kernel-7.0.2-2-pve-signed: 7.0.2-2
proxmox-kernel-6.17.13-7-pve-signed: 6.17.13-7
proxmox-kernel-6.17: 6.17.13-7
proxmox-kernel-6.17.4-2-pve-signed: 6.17.4-2
proxmox-kernel-6.17.2-2-pve-signed: 6.17.2-2
proxmox-kernel-6.14: 6.14.11-8
proxmox-kernel-6.14.11-8-pve-signed: 6.14.11-8
proxmox-kernel-6.14.11-5-pve-signed: 6.14.11-5
proxmox-kernel-6.8.12-13-pve-signed: 6.8.12-13
proxmox-kernel-6.8: 6.8.12-13
proxmox-kernel-6.8.12-4-pve-signed: 6.8.12-4
amd64-microcode: 3.20251202.1~bpo13+1
ceph-fuse: 19.2.3-pve1
corosync: 3.1.10-pve2
criu: 4.1.1-1
frr-pythontools: 10.6.1-1+pve1
ifupdown2: 3.3.0-1+pmx12
ksm-control-daemon: 1.5-1
libjs-extjs: 7.0.0-5
libproxmox-acme-perl: 1.7.1
libproxmox-backup-qemu0: 2.0.2
libproxmox-rs-perl: 0.4.1
libpve-access-control: 9.1.0
libpve-apiclient-perl: 3.4.2
libpve-cluster-api-perl: 9.1.4
libpve-cluster-perl: 9.1.4
libpve-common-perl: 9.1.12
libpve-guest-common-perl: 6.0.2
libpve-http-server-perl: 6.0.5
libpve-network-perl: 1.4.2
libpve-notify-perl: 9.1.4
libpve-rs-perl: 0.13.2
libpve-storage-perl: 9.1.0
libspice-server1: 0.15.2-1+b1
lvm2: 2.03.31-2+pmx1
lxc-pve: 7.0.0-1
lxcfs: 7.0.0-pve1
novnc-pve: 1.7.0-1
proxmox-backup-client: 4.2.0-1
proxmox-backup-file-restore: 4.2.0-1
proxmox-backup-restore-image: 1.0.0
proxmox-firewall: 1.2.2
proxmox-kernel-helper: 9.0.4
proxmox-mail-forward: 1.0.3
proxmox-mini-journalreader: 1.6
proxmox-offline-mirror-helper: 0.7.3
proxmox-widget-toolkit: 5.1.10
pve-cluster: 9.1.4
pve-container: 6.1.6
pve-docs: 9.1.3
pve-edk2-firmware: 4.2025.05-2
pve-esxi-import-tools: 1.0.1
pve-firewall: 6.0.4
pve-firmware: 3.18-3
pve-ha-manager: 5.2.0
pve-i18n: 3.7.1
pve-qemu-kvm: 11.0.0-2
pve-xtermjs: 6.0.0-1
qemu-server: 9.1.10
smartmontools: 7.5-pve2
spiceterm: 3.4.2
swtpm: 0.8.0+pve3
vncterm: 1.9.2
zfsutils-linux: 2.3.4-pve1

Code: 
root@pve:~# pct config 5006
arch: amd64
cmode: console
cores: 1
entrypoint: /app/docker-entrypoint.sh
env: PATH=/opt/java/openjdk/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/binJAVA_HOME=/opt/java/openjdkLANG=en_US.UTF-8LANGUAGE=en_US:enLC_ALL=en_US.UTF-8JAVA_V
ERSION=jdk-21.0.11+10TZ=Europe/ViennaBACKEND_BIND_IP=0.0.0.0BACKEND_PORT=8080BACKEND_URL=http://lxc-bose-soundcork.lan:8000AUTH_SERVICE_URL=http://lxc-bose-soundcork.lan:8000/m
arge/
features: nesting=1
hostname: lxc-bose-soundcork
memory: 512
mp0: local-zfs:subvol-5006-disk-1,mp=/app/backend/state,backup=1,mountoptions=discard,size=4G
mp1: local-zfs:subvol-5006-disk-2,mp=/app/stockholm,backup=1,mountoptions=discard,size=4G
mp2: local-zfs:subvol-5006-disk-3,mp=/app/stockholm_zip,backup=1,mountoptions=discard,ro=1,size=4G
net0: name=eth0,bridge=vmbr050,gw=10.45.50.1,hwaddr=BC:24:11:68:B4:EE,ip=10.45.55.6/32,type=veth
ostype: ubuntu
protection: 1
rootfs: local-zfs:subvol-5006-disk-0,mountoptions=discard,size=16G
swap: 0
tags: lxc
unprivileged: 1
lxc.init.cwd: /app
lxc.signal.halt: SIGTERM

Weil der Inhalt der Nachricht sonst zu lange wäre, hab ich den Output von pct start 5006 --debug als Textdatei angehängt.
 

Attachments

Da scheint das Problem zu liegen:


NOTICE start - ../src/lxc/start.c:start:2375 - Exec'ing "/app/docker-entrypoint.sh"
NOTICE start - ../src/lxc/start.c:post_start:2386 - Started "/app/docker-entrypoint.sh" with pid "1332725"
NOTICE start - ../src/lxc/start.c:signal_handler:479 - Received 17 from pid 1332721 instead of container init 1332725

Der Container versucht als PID 1 ein Docker-Entrypoint-Script (/app/docker-entrypoint.sh) zu starten — also den CMD/ENTRYPOINT eines OCI-Images, nicht /sbin/init. Signal 17 ist SIGCHLD, d.h. der Entrypoint terminiert sofort (z.B. weil er auf eine Docker-Umgebung wartet, ein Sub-Prozess fehlt, oder das Script unter LXC einfach exit'et). Damit ist PID 1 weg und der CT „nicht laufend".

Schnelldiagnose, was der Entrypoint eigentlich macht:
```
pct mount 5006
cat /var/lib/lxc/5006/rootfs/app/docker-entrypoint.sh
# evtl. auch:
ls -la /var/lib/lxc/5006/rootfs/sbin/init /var/lib/lxc/5006/rootfs/usr/sbin/init 2>/dev/nullpct unmount 5006```

```

Mögliche Fixes, je nach Image:


1. Entrypoint im Vordergrund halten — viele Container-Entrypoints enden, wenn sie ihren Hauptprozess via exec ersetzen sollen, das aber unter LXC schief läuft, oder der Hauptprozess geht selbst sofort runter. Im LXC-Config (/etc/pve/lxc/5006.conf) testweise:

```
lxc.init.cmd = /bin/sh -c "tail -f /dev/null
```

Wenn der CT damit läuft, ist es klar ein Entrypoint-/App-Problem, kein LXC-Problem. Dann kannst du via pct enter 5006 reingehen und debuggen, was /app/docker-entrypoint.sh braucht.


2. Echten Init-Prozess davorsetzen — bei OCI-zu-LXC-Konvertierung üblich: tini oder ein minimales systemd/openrc als PID 1, das den Entrypoint als Service startet.


3. Entrypoint-Script anschauen — oft fehlen Env-Vars, die in docker run -e ... gesetzt würden, oder es wird auf /var/run/docker.sock gewartet. Das Script wirft dann z.B. ein exit 1 ohne Output, weil stdout/stderr im OCI-Modell anders gehandhabt werden.
 
Danke für die Hilfe!

Zwar war der Entrypoint Ansatz nicht falsch, aber das Problem saß wohl wieder mal vor dem Computer.

Wie aus den Logs ersichtlich "stirbt" ja der Prozess innerhalb von einem Bruchteil einer Sekunde. Leider ist das für PVE zu schnell und schafft es nicht, die Console anzuhängen und daher hab ich den Output nicht gesehen.

Hab den LXC dann mit lxc-start -n 5006 -F gestartet, wo ich dann meinen Fehler gesehen habe..

Code: 
root@pve:~# lxc-start -n 5006 -F
Please download stockholm.zip first, put it at /app/stockholm_zip/stockholm.zip, and read the README for instructions.

... Ups

Nachdem ich das behoben hatte, konnte der Container dann auch erfolgreich starten :)
1779242211467.png

Zwar konnte die IP Adresse in diesem Fall nicht korrekt gesetzt werden, was aber über eine kleine Abänderung der Konfigurationsdatei korrigiert werden konnte.

Jetzt läuft der Container und ist erreichbar.
 
You must log in or register to reply here.
Top Bottom
Back