linuxserver/docker-unifi-controller

[FEAT] Install controller's `.deb` during image build process

pmalek opened this issue · 7 comments

Is this a new feature request?

  • I have searched the existing issues

Wanted change

I've noticed that controller's image that is downloaded during the image build process in here:

curl -o \
/app/unifi.deb -L \
"https://dl.ui.com/unifi/${UNIFI_VERSION}/unifi_sysvinit_all.deb" && \
is not being installed at that stage. This causes the container's startup time to take longer since the .deb has to be installed on every container restart.

This is especially noticeable on slower hardware like Raspberry PI (with slow IO). In the logs below notice that installing takes around 20 seconds and takes between 2 to 4 cores during that time.

2023-01-23T12:39:13.211042462+01:00 cont-init: info: /etc/cont-init.d/10-adduser exited 0
2023-01-23T12:39:13.211130424+01:00 cont-init: info: running /etc/cont-init.d/15-install
2023-01-23T12:39:13.221440560+01:00 *** installing unifi packages ***
2023-01-23T12:39:13.324239234+01:00 Selecting previously unselected package unifi.
2023-01-23T12:39:13.350658105+01:00 (Reading database ... 9470 files and directories currently installed.)
2023-01-23T12:39:13.353030696+01:00 Preparing to unpack /app/unifi.deb ...
2023-01-23T12:39:13.725400998+01:00 Unpacking unifi (7.3.76-19582-1) ...
2023-01-23T12:39:32.540071860+01:00 Setting up unifi (7.3.76-19582-1) ...
2023-01-23T12:39:33.435774326+01:00 invoke-rc.d: could not determine current runlevel
2023-01-23T12:39:33.444156571+01:00 invoke-rc.d: policy-rc.d denied execution of start.
2023-01-23T12:39:33.496826889+01:00 cont-init: info: /etc/cont-init.d/15-install exited 0
2023-01-23T12:39:33.496925407+01:00 cont-init: info: running /etc/cont-init.d/20-config
2023-01-23T12:39:33.558028451+01:00 *** Setting Java memory limit to 2048 ***
2023-01-23T12:39:33.558113987+01:00 *** Setting Java memory minimum to 1024 ***

Reason for change

Slow container startup.

Proposed code change

Install the .deb during process build and remove the installation service at

if [[ ! -d /usr/lib/unifi/bin ]]; then
echo "*** installing unifi packages ***"
export DEBIAN_FRONTEND=noninteractive
dpkg -i /app/unifi.deb
fi

Thanks for opening your first issue here! Be sure to follow the bug or feature issue templates!

The alternative is 3-5 minute startups for users affected by the overlayfs cow bug.

FWIW it doesn't install on every restart, only on recreation of the container.

Hm, but /usr/lib/unifi/ is not mounted (nor should it be, right?) or mentioned in the README. Hence each time I restart the container it does install it.

I guess to workaround this limitation I could add a mount for that dir but that doesn't feel right 🤔.

(I'm running this on k3s cluster FWIW)

A restart persists the container filesystem.

Hm, but /usr/lib/unifi/ is not mounted (nor should it be, right?) or mentioned in the README. Hence each time I restart the container it does install it.

Correct, it should not be mounted. What this approach gives us, is one less interaction with files on startup, as the alternative is chowning a decent amount of files.

A restart persists the container filesystem.

When running as a plain container, yes. When running on k8s, nope.

That is true, however we will stick to the current implementation, as that caters to the largest amount of our users.