DEBUG conf - conf.c:run_buffer:305 - Script exec /usr/share/lxcfs/lxc.mount.hook 100 lxc mount produced output: missing /var/lib/lxcfs/proc/ - lxcfs not running?
is lxcfs running?
* `systemctl status -l lxcfs`
* `journalctl -u lxcfs.service`
DEBUG conf - conf.c:run_buffer:305 - Script exec /usr/share/lxcfs/lxc.mount.hook 100 lxc mount produced output: missing /var/lib/lxcfs/proc/ - lxcfs not running?
root@vhost07 ~ # systemctl status -l lxcfs
● lxcfs.service - FUSE filesystem for LXC
Loaded: loaded (/lib/systemd/system/lxcfs.service; enabled; vendor preset: enabled)
Active: inactive (dead) since Mon 2021-07-12 11:48:38 CEST; 38min ago
Docs: man:lxcfs(1)
Main PID: 655 (code=exited, status=0/SUCCESS)
Jun 06 08:44:29 vhost07 lxcfs[655]: - cpuview_daemon
Jun 06 08:44:29 vhost07 lxcfs[655]: - loadavg_daemon
Jun 06 08:44:29 vhost07 lxcfs[655]: - pidfds
Jul 12 11:40:33 vhost07 systemd[1]: Reloading FUSE filesystem for LXC.
Jul 12 11:40:33 vhost07 systemd[1]: Reloaded FUSE filesystem for LXC.
Jul 12 11:48:38 vhost07 systemd[1]: Stopping FUSE filesystem for LXC...
Jul 12 11:48:38 vhost07 lxcfs[655]: Running destructor lxcfs_exit
Jul 12 11:48:38 vhost07 fusermount[2285342]: /bin/fusermount: failed to unmount /var/lib/lxcfs: Invalid argument
Jul 12 11:48:38 vhost07 systemd[1]: lxcfs.service: Succeeded.
Jul 12 11:48:38 vhost07 systemd[1]: Stopped FUSE filesystem for LXC
-- Boot cb9439213de34d469d5d96be11c18e40 --
Jun 06 08:44:28 vhost07 systemd[1]: Started FUSE filesystem for LXC.
Jun 06 08:44:29 vhost07 lxcfs[655]: Running constructor lxcfs_init to reload liblxcfs
Jun 06 08:44:29 vhost07 lxcfs[655]: mount namespace: 4
Jun 06 08:44:29 vhost07 lxcfs[655]: hierarchies:
Jun 06 08:44:29 vhost07 lxcfs[655]: 0: fd: 5:
Jun 06 08:44:29 vhost07 lxcfs[655]: 1: fd: 6: name=systemd
Jun 06 08:44:29 vhost07 lxcfs[655]: 2: fd: 7: memory
Jun 06 08:44:29 vhost07 lxcfs[655]: 3: fd: 8: cpu,cpuacct
Jun 06 08:44:29 vhost07 lxcfs[655]: 4: fd: 9: net_cls,net_prio
Jun 06 08:44:29 vhost07 lxcfs[655]: 5: fd: 10: devices
Jun 06 08:44:29 vhost07 lxcfs[655]: 6: fd: 11: hugetlb
Jun 06 08:44:29 vhost07 lxcfs[655]: 7: fd: 12: rdma
Jun 06 08:44:29 vhost07 lxcfs[655]: 8: fd: 13: perf_event
Jun 06 08:44:29 vhost07 lxcfs[655]: 9: fd: 14: pids
Jun 06 08:44:29 vhost07 lxcfs[655]: 10: fd: 15: blkio
Jun 06 08:44:29 vhost07 lxcfs[655]: 11: fd: 16: cpuset
Jun 06 08:44:29 vhost07 lxcfs[655]: 12: fd: 17: freezer
Jun 06 08:44:29 vhost07 lxcfs[655]: Kernel supports pidfds
Jun 06 08:44:29 vhost07 lxcfs[655]: Kernel supports swap accounting
Jun 06 08:44:29 vhost07 lxcfs[655]: api_extensions:
Jun 06 08:44:29 vhost07 lxcfs[655]: - cgroups
Jun 06 08:44:29 vhost07 lxcfs[655]: - sys_cpu_online
Jun 06 08:44:29 vhost07 lxcfs[655]: - proc_cpuinfo
Jun 06 08:44:29 vhost07 lxcfs[655]: - proc_diskstats
Jun 06 08:44:29 vhost07 lxcfs[655]: - proc_loadavg
Jun 06 08:44:29 vhost07 lxcfs[655]: - proc_meminfo
Jun 06 08:44:29 vhost07 lxcfs[655]: - proc_stat
Jun 06 08:44:29 vhost07 lxcfs[655]: - proc_swaps
Jun 06 08:44:29 vhost07 lxcfs[655]: - proc_uptime
Jun 06 08:44:29 vhost07 lxcfs[655]: - shared_pidns
Jun 06 08:44:29 vhost07 lxcfs[655]: - cpuview_daemon
Jun 06 08:44:29 vhost07 lxcfs[655]: - loadavg_daemon
Jun 06 08:44:29 vhost07 lxcfs[655]: - pidfds
Jul 12 11:40:33 vhost07 systemd[1]: Reloading FUSE filesystem for LXC.
Jul 12 11:40:33 vhost07 systemd[1]: Reloaded FUSE filesystem for LXC.
Jul 12 11:48:38 vhost07 systemd[1]: Stopping FUSE filesystem for LXC...
Jul 12 11:48:38 vhost07 lxcfs[655]: Running destructor lxcfs_exit
Jul 12 11:48:38 vhost07 fusermount[2285342]: /bin/fusermount: failed to unmount /var/lib/lxcfs: Invalid argument
Jul 12 11:48:38 vhost07 systemd[1]: lxcfs.service: Succeeded.
Jul 12 11:48:38 vhost07 systemd[1]: Stopped FUSE filesystem for LXC.
not quitelxcfs show running:
Active: inactive (dead)
Thanks after restart lxcfs is working now the startupnot quite
try restarting it with `systemctl restart lxcfs` (or if possible maybe just reboot the node)
I hope this helps!
Jul 12 13:42:21 turnkey-docker dockerd[969]: time="2021-07-12T13:42:21.695603476Z" level=warning msg="Your kernel does not support cgroup memory limit"
Jul 12 13:42:21 turnkey-docker dockerd[969]: time="2021-07-12T13:42:21.695683015Z" level=warning msg="Unable to find cpu cgroup in mounts"
Jul 12 13:42:21 turnkey-docker dockerd[969]: time="2021-07-12T13:42:21.695764428Z" level=warning msg="Unable to find blkio cgroup in mounts"
Jul 12 13:42:21 turnkey-docker dockerd[969]: time="2021-07-12T13:42:21.695845461Z" level=warning msg="Unable to find cpuset cgroup in mounts"
Jul 12 13:42:21 turnkey-docker dockerd[969]: time="2021-07-12T13:42:21.696277343Z" level=warning msg="mountpoint for pids not found"
Jul 12 13:42:21 turnkey-docker dockerd[969]: time="2021-07-12T13:42:21.697084420Z" level=info msg="stopping event stream following graceful shutdown" error="context canceled" module=libcontainerd namespace=plugins.moby
Jul 12 13:42:21 turnkey-docker dockerd[969]: time="2021-07-12T13:42:21.697200348Z" level=info msg="stopping healthcheck following graceful shutdown" module=libcontainerd
Jul 12 13:42:21 turnkey-docker dockerd[969]: time="2021-07-12T13:42:21.699779568Z" level=info msg="pickfirstBalancer: HandleSubConnStateChange: 0xc000047650, TRANSIENT_FAILURE" module=grpc
Jul 12 13:42:21 turnkey-docker dockerd[969]: time="2021-07-12T13:42:21.700182876Z" level=info msg="pickfirstBalancer: HandleSubConnStateChange: 0xc000047650, CONNECTING" module=grpc
Jul 12 13:42:22 turnkey-docker dockerd[969]: Error starting daemon: Devices cgroup isn't mounted
This was my issue too. Tried many different troubleshooting ideas with no success yet.Is there a way to downgrade back down to Proxmox 6? After I did the upgrade, my lxc container can't run Docker anymore.
Error:
Code:Jul 12 13:42:21 turnkey-docker dockerd[969]: time="2021-07-12T13:42:21.695603476Z" level=warning msg="Your kernel does not support cgroup memory limit" Jul 12 13:42:21 turnkey-docker dockerd[969]: time="2021-07-12T13:42:21.695683015Z" level=warning msg="Unable to find cpu cgroup in mounts" Jul 12 13:42:21 turnkey-docker dockerd[969]: time="2021-07-12T13:42:21.695764428Z" level=warning msg="Unable to find blkio cgroup in mounts" Jul 12 13:42:21 turnkey-docker dockerd[969]: time="2021-07-12T13:42:21.695845461Z" level=warning msg="Unable to find cpuset cgroup in mounts" Jul 12 13:42:21 turnkey-docker dockerd[969]: time="2021-07-12T13:42:21.696277343Z" level=warning msg="mountpoint for pids not found" Jul 12 13:42:21 turnkey-docker dockerd[969]: time="2021-07-12T13:42:21.697084420Z" level=info msg="stopping event stream following graceful shutdown" error="context canceled" module=libcontainerd namespace=plugins.moby Jul 12 13:42:21 turnkey-docker dockerd[969]: time="2021-07-12T13:42:21.697200348Z" level=info msg="stopping healthcheck following graceful shutdown" module=libcontainerd Jul 12 13:42:21 turnkey-docker dockerd[969]: time="2021-07-12T13:42:21.699779568Z" level=info msg="pickfirstBalancer: HandleSubConnStateChange: 0xc000047650, TRANSIENT_FAILURE" module=grpc Jul 12 13:42:21 turnkey-docker dockerd[969]: time="2021-07-12T13:42:21.700182876Z" level=info msg="pickfirstBalancer: HandleSubConnStateChange: 0xc000047650, CONNECTING" module=grpc Jul 12 13:42:22 turnkey-docker dockerd[969]: Error starting daemon: Devices cgroup isn't mounted
I tried to set "systemd.unified_cgroup_hierarchy=0" in GRUB_CMDLINE_LINUX, but that hinders the container from starting, as mentioned earlier.
What I can tell it probably has to do with the change in Proxmox 7 that cgroup v2 instead of cgroup is used.
Also running "cgroupfs-umount" followed by "cgroupfs-mount" didn't help, neither in the host nor in the guest
Please mention this as a big warning somewhere in the beginning of the release note, that folks running Centos 7 and we are a lot should not upgrade. I just upgraded all my cluster to discover after reboot that all my containers (90% centos 7 adn 10% debian 10) have no network interfaces up and no services running and issuing an ifconfig ethX up starts the interface with no ip address, ..., no routing, Is there a way to go back ?this is an issue with the new cgroupv2 feature affecting "old" distros like Centos 7 and Ubuntu 16.04. we're working on improving the handling there.
yes, please read the upgrade documentation!Please mention this as a big warning somewhere in the beginning of the release note, that folks running Centos 7 and we are a lot should not upgrade. I just upgraded all my cluster to discover after reboot that all my containers (90% centos 7 adn 10% debian 10) have no network interfaces up and no services running and issuing an ifconfig ethX up starts the interface with no ip address, ..., no routing, Is there a way to go back ?
--full
, which also checks all containers for incompatible distros.Thanks fabian, i run the check and had a warning for only one container and thus proceeded to the upgrade. As not understanding the implications of incompatibility with cgroupv2 vs cgroupv1 I admit not having read the upgrade documentation carefully. My appologies for my previous comment.yes, please read the upgrade documentation!
https://pve.proxmox.com/wiki/Upgrade_from_6.x_to_7.0#Old_Container_and_CGroupv2
you confirmed that you read those instructions before proceeding with the upgrade - and those instructions prominently mention running the check script, at least once with--full
, which also checks all containers for incompatible distros.
Have you by any chance been using systemd from backports?
By file system quotas, do you mean file system quotas for users inside the LXC?CGroup Version Compatibility: Another important difference is that the devices controller is configured in a completely different way. Because of this, file system quotas are currently not supported in a pure cgroupv2 environment.
Inside the container, yes, via quota-tools (quotacheck/edquota & friends). Supporting this will require some bigger changes to how we start up containers.By file system quotas, do you mean file system quotas for users inside the LXC?
Are quotas likely to be supported in cgroupv2 in the future?
Do you think those changes in 7.x to starting up containers to enable cgroupv2 user quotas will/could be done before 6.4 reaches EoL?Inside the container, yes, via quota-tools (quotacheck/edquota & friends). Supporting this will require some bigger changes to how we start up containers.
Inside the container, yes, via quota-tools (quotacheck/edquota & friends). Supporting this will require some bigger changes to how we start up containers.
Which issue exactly? As general announcement thread this is a relatively big one with many topics in there. FS quota support inside cgv2 containers isn't actively worked on IIRC, you could use VMs for such use cases, they provided a better isolation in general, which is often goes a long with the case where user quotas are a requirement.Is there any updates on this issue ?
Im sorry, i was talking about he quotas on lxc container.Which issue exactly? As general announcement thread this is a relatively big one with many topics in there. FS quota support inside cgv2 containers isn't actively worked on IIRC, you could use VMs for such use cases, they provided a better isolation in general, which is often goes a long with the case where user quotas are a requirement.