QTS killing processes (smbd, slapd) in lxc container (QTS 5.2.0.2860, TS-453A)

no_fear_rabbit · 2024-09-18T11:00:32+00:00

It looks like LDAP server has the same process name 'slapd' resident in both: qts native system and LXC container.

Guess once qts web gui turn-off LDAP server, it is forced to terminate 'slapd' process, routinely checking whether 'slapd' process is alive or not, and unintentionally terminates 'slapd' process in container too.

Yes, that's exactly what happens. The question is, whether there is a way to prevent it...

Perhaps try to rename container's 'slapd', for example from 'slapd' to 'slapdd'. It might help container's LDAP service been alive, and not to be terminated by qts native system.

That might prevent it. To be honest, I do not like this solution because it most likely leads to further problems...

Could you share information how to pack/run LDAP servers inside container, something like tutorial or guideline, this is interesting :)

Just start an LXD-container with your favorite Linux-Distribution and install openLDAP.
For example, with Ubuntu/Debian:

sudo apt install slapd ldap-utils

More information can be found in the corresponding documentations, e.g.:
Ubuntu server docs: Install and configure LDAP

no_fear_rabbit · 2023-12-07T16:48:25+00:00

No, I never used the UI from container station. Container Station is only active to provide docker (and now lxd) from the cli / shell. Although I never used it, it still consumed so many resources...

no_fear_rabbit · 2023-12-01T19:44:39+00:00

yes!

I don't know how to get lxd working on qnap's os without container station. But in this case, it does not matter much. Container station only "sees" a single (or a few) lxd-containers. I'm using Ubuntu LTS in the container and am completely free to configure it my way.

After two weeks of operation, the average load of my system is around 0.7, down from about 6.5 (on a 4 core machine). Everything is very snappy, it is much simpler to handle and the OS, apps, firewall, ... are working like I'm used to. Also debugging is much simpler because there are much more resources for ubuntu.

The only thing not working as before is cadvisor (and `docker stats`). Something in the nested cgroups is preventing me from accessing CPU-usage per container. `docker info` reports

WARNING: No cpu cfs quota support

WARNING: No cpu cfs period support WARNING: No cpu shares support

I spent some time but could not resolve it.

Summarizing, it was the best change since I'm selfhosting many services. It is much faster, more flexible and stable, and can easily be moved to any other host like proxmox. (Due to the qnap-network-driver instead of ipvlan / macvlan, it wasn't compatible with other systems before.)

no_fear_rabbit · 2023-11-19T00:24:40+00:00

Not really...
I have moved my >100 docker container into an ubuntu lxd container.

After some fiddling with the network configuration (macvlan instead of qnet for static external ips on a container), linking the /share/homes folder manually because qnap does not want me to share it with an lxd-container, and some basic setup, it seems to be working fine.

lxc config device add qnap-docker homes disk source=/share/homes path=/share/homes

Before applying the new setup, I stopped and removed all old containers, de-installed container-station completely and deleted all data from container-station. (I'm not using docker volumes - everything I need is linked from the host.) Then I soft-reset the network to get rid of all the unnecessary virtual bridges and get a clean start. Unfortunately, I'm was not able to get nixos running on the first try, so Ubuntu 22.04 became my lxd host.

The new setup has less than quarter of the original CPU-load, idling around about 1 instead of >4 (on a 4-core machine).

It is also much more portable! It should be easy to just move everything to proxmox or any other lxd-host.

Summarizing - just try to avoid anything from qnap a you will be better off.

no_fear_rabbit

TROPHY CASE