[SOLVED] PMG in a LXC container: 'timedatectl show' fails (used by UI)

sthielo

New Member
Mar 17, 2025
10
5
3
TOPIC 1) timedatectl failure (UI ... and shell)
first time I noticed after recent update:
UI-Configuration-System shows an error "command 'timedatectl show' --property=Timezone' failed: exit code 1 (500)

and actually in shell [of PMG LXC as root]: timedatectl show -> Failed to connect to system scope bus via local transport: No such file or directory

How to get rid of that? Is that new issue - I never noticed before? Is UI/API supposed to use timedatectl or does that break LXC support?

TOPIC 2) sys-kernel-config.mount failed
while searching for info: finding some other issues (systemctl degraded: sys-kernel-config.mount) in journalctl, made me migrate (backup/restore) to a privileged LXC, which solved that issue, but still has the timedatectl issue.

I would prefer to have a non-privileged one. Doc says LXC is supported. Is 'unprivileged' LXC for PMG supported? ... then how to properly solve the sys-kernel-config.mount issue in an unprivileged container?

Code:
proxmox-mailgateway-container: 9.0.0 (API: 9.0.7/d11aa4b692ae, running kernel: 7.0.0-3-pve)
pmg-api: 9.0.7
pmg-gui: 5.0.5
clamav-daemon: 1.4.3+dfsg-1
ifupdown: residual config
ifupdown2: 3.3.0-1+pmx12
libarchive-perl: 3.7.4.1
libjs-extjs: 7.0.0-5
libproxmox-acme-perl: 1.7.1
libproxmox-acme-plugins: 1.7.1
libpve-apiclient-perl: 3.4.2
libpve-common-perl: 9.1.12
libpve-http-server-perl: 6.0.5
libxdgmime-perl: 1.2.0
lvm2: not correctly installed
pmg-docs: 9.0.6
pmg-i18n: 3.7.3
pmg-log-tracker: 3.0.1
proxmox-mini-journalreader: 1.6
proxmox-spamassassin: 4.0.2-1
proxmox-widget-toolkit: 5.2.2
pve-xtermjs: 6.0.0-1

This looks to me like a container topic. Any hint/help how to solve or track down appreciated.
 
  • Like
Reactions: Sunilkumar
please post the full config of the container..
 
config of container in PVE

Code:
[~]$ pct config 204   
arch: amd64
cores: 2
features: nesting=1
hostname: mailgw
memory: 4096
nameserver: 192.168.101.203
net0: name=eth0,bridge=v101,gw=192.168.101.1,hwaddr=BC:24:11:91:72:90,ip=192.168.101.204/24,type=veth
onboot: 1
ostype: debian
rootfs: thvmstore:vm-204-disk-0,mountoptions=discard,size=10G
searchdomain: thiel.internal thiel.team
startup: order=10
swap: 1024
 
  • Like
Reactions: Sunilkumar
okay, that looks correct. anything visible in the logs? does the problem persist if you reboot the container?
 
  • Like
Reactions: Sunilkumar
- persist on reboots. ... updated to newest packages before posting and rebooted. ... same error
- nothing suspicious in /var/log/**/* or journalctl . systemctl status is happy.

only that error mentioned in UI and when executing on cmdline.
note: actually everything seems to work fine, but that UI error and timedatectl in shell (is that supposed to work within a LXC?)
 
yes, it is.. anything visible in the host journal?

note that privileged containers are not recommended for security reasons, the second issue from your original post is benign and can be ignored.
 
topic 1)
note: ... meanwhile I upgraded [and rebooted] the pve hosts to see if that changes anything (last upgrade was ~20d ago ... but things change fast ;-) )
=> no change. BTW: same behavior on an other host, which I tested while the CT was migrated (stopped/started) to another host by ha-manager during the upgrade procedure.

journalctl on host-PVE does not show anything suspicious, too

I would expect something on PMG-LXC for
a) systemctl | grep dbus (isn't that the thing that timedatectl's err msg is referring to) and
b) systemctl | grep time (other then *.timers, proc-uptime.mount, timers.target) ... so something like *timedated* or *timed*
systemctl list-unit-files at least shows systemd-timedated.service static -
but for dbus it only hows some entries for freedesktop with state 'alias'

note: I have a PBS as container/LXC in my homelab which shows dbus.service and dbus.socket and systemd-timedated.service ... and timedatectl works there!
the only "similar" container. as everything else in containers is using Alpine.


-------
topic 2)
... I converted back to "unprivileged" - thanks
sys-kernel-config.mount loaded failed failed is back in systemctl ... I'm ignoring it.
 
  • Like
Reactions: Sunilkumar
yes, it seems the dbus-system-bus is only recommended by systemd, and hence missing in this minimal container. could you try installing the "dbus" package?
 
YES - it was as simple as that. apt install dbus && systemctl start dbus
So, I do NOT understand how this package can be missing. ok, my container is quite old (2021) made some upgrades ... even some major ones from 8 to 9.
Thanks a lot.