Search results

Its likely you wouldn't have been able to boot it in the old system either.Your initrd is either missing the lvm module or in the wrong location on the LVM partition. Basically you can hook up a rescue CD with the same bitness (32-bit or 64-bit) as the system that is on this disk For example...

If so, you could be running into the Swap on ZFS problem because you are reserving more memory. https://forum.proxmox.com/threads/zfs-swap-crashes-system.25208/#post-126215

If you are using ZFS storage, then you can use the method that user bank mentioned earlier in this thread to deactivate posix acls. Or you can do, ( If you really don't need them :-) ): find / -xdev -type d -exec setfacl -k {} \; Or setfacl -b -R /

Yes, it must be in the Service section. Doesn't matter on which line inside the section. After changing the file, to get it applied you need to do: systemctl daemon-reload systemctl restart lxcfs

Maybe it would also make a difference to add a: Nice=-20 In the Service section of the /etc/systemd/system/multi-user.target.wants/lxcfs.service file and restart the lxcfs service.

It's a relative setting. If you increase all, it has zero effect. You must interpret this as the weight you give a container with respect to other containers. If they all have the same weight, then they all get the same amount of cpu time.

No, I think it is lxcfs not being able to keep up with quickly spawning deamons and a stressed process scheduler that is hurting you. It uses a process in the container to read process ids, and normal processes get scheduled out also. Maybe it helps to give the busiest container more CPU priority.

Okay. Is it an error with one container while others continue running? Or do all your systemd lxc containers get stuck, not able to restart services or display top? Did you get the send_creds errors again in the syslog? Any other errors around the same time in the syslog? In the stuck...

Looking back at your software list, I notice that you have or had lxcfs 0.13-pve1. The current version is lxcfs 0.13-pve2. There have been some fixes in it. Also the newest kernel patch may help with the postfix errors that were visible in the logs. It may be that you can't reproduce anymore...

So this permissions problem cannot only affect sockets, but also other files. It will be less harmful with normal files because files are usually written to by their owners, and created 644 anyway, but still you have to watch out for it. The problem I mentioned about postfix is actually a...

Okay guys, I think I got to the bottom of this socket permissions thing. What is happening that apparently openVZ didn't support the posix acls in the filesystem or the backup restore inserts posix acls. No matter how they got there, the filesystem now has posix acls enabled. I tested this...

I looked up some logs, and actually the recursive_rmdir error seems 'normal'. The send_creds and other errors not however.

It may be that one container shutdown ruins things for other running containers. Or it maybe that these error messages are actually totally unrelated. In any case, not being able to restart services and problems with top indicate that lxcfs is not responding anymore, and consequently systemd...

Can you tie the recursive rm_dir errors to moments of shutdown of that container? It's probably a race condition on shutdown, where lxc-stop tries to remove there dirs while the container is still hanging on to them. It sometimes can happen on start too, but only if the container is improperly...

You need to check the output of dpkg to see if the kernel package is 4.2.6-28, because 4.2.6-26 also displays the same uname. And of course reboot. dpkg -l | grep kernel Of course there is always the possibility that these socket problems are actually unrelated problems requiring a different...

The Transport error is very likely originated by lxcfs, which is a tool that can allow containers with systemd to still interact with the cgroup system and display correct uptime and memory for the container. https://linuxcontainers.org/lxcfs/introduction/...

If you blind type reset<enter> after you get kicked, you will have your tty output reconnected. stty sane, also works after you get kicked.

Maybe if this bug gets more "Fire" then we will know earlier if this is stable: https://bugs.launchpad.net/ubuntu/+source/lxc/+bug/1446906 It is reported for Ubuntu Vivid, but it also affects Ubuntu Wily, and I suspect everyone with at least lxc 1.1.2 or higher. It seems something changed in...

The 4.2.6-28 kernel from the no subscription repository does enable the postfix sockets to work.

It looks like some problems with sockets are getting fixed quite soon :) https://git.proxmox.com/?p=pve-kernel.git;a=commitdiff;h=c579c08545b636b97b7f2c14ede9e669e8d8595b Could be that some programs try to chmod the socket after having created and disconnected from it. Which would explain that...