Hi,
I run an application container (OCI image) with a short-lived entrypoint on Proxmox VE 9.x. Every start task ends in error, although the container does start, runs its job and exits cleanly.
Setup
- lxc-pve: 7.0.0-2, pve-container: 6.1.18 (after apt full-upgrade today; same behaviour before and after the update)
- CT 106: unprivileged, created from an OCI image, entrypoint: dumb-init -- npm run load-data (Node.js job)
- The CT is started from the host's crontab every 4 minutes with "pct start 106". The job takes about 60-75 s, then the entrypoint exits and the CT stops.
Problem
Each "pct start 106" prints:
and the vzstart task ends in error:
However, right after the error the CT is actually running:
and the journal shows a clean run of about 74 s:
The job itself completes (I see its output in the CT console). So it looks like the PID lookup of the start task happens before the LXC monitor socket is available, a race that only shows up with this kind of container.
Note: "pct start 106 --debug" prints the same monitor socket error and does not create /tmp/lxc-106.log.
CT config (environment variables omitted)
pveversion -v
Questions
1. Is this a known issue, or expected for application containers whose entrypoint exits?
2. Is there a recommended way to run one-shot / short-lived OCI CTs, other than keeping the CT running with a loop in the entrypoint?
3. Is there any other log I should collect?
Thanks!
I run an application container (OCI image) with a short-lived entrypoint on Proxmox VE 9.x. Every start task ends in error, although the container does start, runs its job and exits cleanly.
Setup
- lxc-pve: 7.0.0-2, pve-container: 6.1.18 (after apt full-upgrade today; same behaviour before and after the update)
- CT 106: unprivileged, created from an OCI image, entrypoint: dumb-init -- npm run load-data (Node.js job)
- The CT is started from the host's crontab every 4 minutes with "pct start 106". The job takes about 60-75 s, then the entrypoint exits and the CT stops.
Problem
Each "pct start 106" prints:
Code:
failed to connect to monitor socket: Connection refused
unable to get PID for CT 106 (not running?)and the vzstart task ends in error:
Code:
Nov 09 08:36:02 promox pct[3237989]: starting CT 106: UPID:promox:00316865:299865FE:6AF177E2:vzstart:106:root@pam:
Nov 09 08:36:02 promox pct[3237989]: unable to get PID for CT 106 (not running?)
Nov 09 08:36:02 promox pct[3237988]: <root@pam> end task UPID:promox:00316865:299865FE:6AF177E2:vzstart:106:root@pam: unable to get PID for CT 106 (not running?)However, right after the error the CT is actually running:
Code:
# pct start 106; pct status 106; lxc-info -n 106
failed to connect to monitor socket: Connection refused
unable to get PID for CT 106 (not running?)
status: running
Name: 106
State: RUNNING
PID: 3258393
IP: 192.168.1.58and the journal shows a clean run of about 74 s:
Code:
Nov 09 09:04:02 promox systemd[1]: Started pve-container@106.service - PVE LXC Container: 106.
Nov 09 09:05:16 promox systemd[1]: pve-container@106.service: Deactivated successfully.The job itself completes (I see its output in the CT console). So it looks like the PID lookup of the start task happens before the LXC monitor socket is available, a race that only shows up with this kind of container.
Note: "pct start 106 --debug" prints the same monitor socket error and does not create /tmp/lxc-106.log.
CT config (environment variables omitted)
Code:
arch: amd64
cmode: console
cores: 1
entrypoint: dumb-init -- npm run load-data
features: nesting=1
hostname: recovery-matches-hall-e
memory: 512
net0: name=eth0,bridge=vmbr0,firewall=1,gw=192.168.1.1,host-managed=1,hwaddr=BC:24:11:E3:C4:93,ip=192.168.1.58/24,type=veth
ostype: debian
rootfs: SSD-DATA:vm-106-disk-0,size=8G
swap: 512
unprivileged: 1
lxc.init.uid: 1001
lxc.init.gid: 1001
lxc.init.cwd: /app
lxc.signal.halt: SIGTERMpveversion -v
Code:
proxmox-ve: 9.2.0 (running kernel: 7.0.14-12-pve)
pve-manager: 9.2.26 (running version: 9.2.26/41a0e2e09b9e6f9d)
proxmox-kernel-helper: 9.2.1
proxmox-kernel-7.0: 7.0.14-28
proxmox-kernel-7.0.14-28-pve-signed: 7.0.14-28
proxmox-kernel-7.0.14-25-pve-signed: 7.0.14-25
proxmox-kernel-7.0.14-12-pve-signed: 7.0.14-12
proxmox-kernel-6.17: 6.17.13-21
proxmox-kernel-6.17.13-21-pve-signed: 6.17.13-21
proxmox-kernel-6.17.2-1-pve-signed: 6.17.2-1
amd64-microcode: 3.20251202.1~bpo13+1
ceph-fuse: 19.2.6-pve4
corosync: 3.2.0-pve1
criu: 4.1.1-1
frr-pythontools: 10.6.1-1+pve3
ifupdown2: 3.3.0-1+pmx13
ksm-control-daemon: 1.5-1
libjs-extjs: 7.0.0-9
libproxmox-acme-perl: 1.7.2
libproxmox-backup-qemu0: 2.0.4
libproxmox-rs-perl: 0.4.2
libpve-access-control: 9.2.0
libpve-apiclient-perl: 3.4.3
libpve-cluster-api-perl: 9.1.9
libpve-cluster-perl: 9.1.9
libpve-common-perl: 9.2.8
libpve-guest-common-perl: 6.0.7
libpve-http-server-perl: 6.0.7
libpve-network-perl: 1.6.8
libpve-notify-perl: 9.1.9
libpve-rs-perl: 0.16.0
libpve-storage-perl: 9.1.15
libspice-server1: 0.15.2-1+b1
lvm2: 2.03.31-2+pmx1
lxc-pve: 7.0.0-2
lxcfs: 7.0.0-pve1
novnc-pve: 1.7.0-2
proxmox-backup-client: 4.2.10-1
proxmox-backup-file-restore: 4.2.10-1
proxmox-backup-restore-image: 1.1.0
proxmox-enterprise-support-keyring: 1.1
proxmox-firewall: 1.2.4
proxmox-kernel-helper: 9.2.1
proxmox-mail-forward: 1.1.0
proxmox-mini-journalreader: 1.7
proxmox-offline-mirror-helper: 0.8.0
proxmox-widget-toolkit: 5.2.12
pve-cluster: 9.1.9
pve-container: 6.1.18
pve-docs: 9.2.13
pve-edk2-firmware: 4.2026.08-1
pve-esxi-import-tools: 1.0.1
pve-firewall: 6.0.7
pve-firmware: 3.18-9
pve-ha-manager: 5.2.5
pve-i18n: 3.11.0
pve-qemu-kvm: 11.1.3-1
pve-xtermjs: 6.0.0-3
qemu-server: 9.2.15
smartmontools: 7.5-pve2
spiceterm: 3.4.2
swtpm: 0.10.2+pve1
vncterm: 1.9.2
zfsutils-linux: 2.4.4-pve1Questions
1. Is this a known issue, or expected for application containers whose entrypoint exits?
2. Is there a recommended way to run one-shot / short-lived OCI CTs, other than keeping the CT running with a loop in the entrypoint?
3. Is there any other log I should collect?
Thanks!