jcberthon / unifi-docker

Unifi Controller Docker image and compose
MIT License
30 stars 5 forks source link

Site Migration - Instance doesn't recover after reboot #6

Closed spelliott7 closed 5 years ago

spelliott7 commented 5 years ago

I created everything you did here after finding this fork off of a write up on Reddit I found. I replicated the entire site - actually several times and have attempted to import my old site running on Windows to this server / docker. At the beginning, with the data folders mapped to my home directory as in your README, I select to restore from a backup and upload my file. As soon as that happens the site goes to "reboot" but just shuts down. With Portainer I see it's stopped and I then restart it, which looks like it collected the data but I can never log in. The password is blown up and even docker exec bashing in and playing with Mongo I can find no data. It actually looks like it's looking in an empty database, one that isn't in the data folder at all. At that point I'm unable to continue and have tried multiple things to get this working.

Any ideas on what else I can try? I did try to start the container, go through the wizard, then import my site with the same results. Import, does stuff, reboots, and back to the same instance but no data import. Imported back to my old controller to troubleshoot and it works there. Thanks in advance. Let me know what data I can put together if needed.

jcberthon commented 5 years ago

It is an issue I would need some time to investigate.

I will first try to replicate it at home.

In the mean time, did you try to check the logs and see if mongo reported an error during the import?
Inside the container, under /var/log/unifi you can find the file mongod.log and server.log. It would be interesting to see if you have any errors at the time of the import.

In the examples I have given in the README file, those are really only for testing. For production, you would want to use something like:

$ docker run --detach --cap-drop ALL --restart unless-stopped \
  -e TZ='Europe/Berlin' \
  -p 8080:8080 -p 8443:8443 -p 8843:8843 -p 10001:10001/udp \
  -v ~/unifi/data:/var/lib/unifi \
  -v ~/unifi/logs:/var/log/unifi \
  --name unifi jcberthon/unifi

The above command will spawn the container in the background and tell the Docker daemon to monitor it and restart it automatically if it exits (see the documentation for the meaning of the different values of the restart command). At least when your container fails due to an error, Docker will restart it for you. The docker-compose.yml file in the root of this project provides good default for a production environment.

Another reason why it could failed during import is when the container would be using more RAM than allowed. I have tested the container with a limit of 768MB for a small site (1 AP + 1 Switch) and it works. It might not be sufficient for a bigger site, or during import. While importing, the Unifi software might load the file in memory (including all historical records) and import that into the DB. I have never tested an import of a big site or a small site with a big history, so I do not know how much memory it requires. The developer of the unifi application are better placed than me to tell you.
If your container ran out of memory, the Linux host should have logged it inside syslog. You can check syslog by using the journalctl command (for systemd based systems) or by checking the syslog file (which could be either messages or syslog and which is usually under /var/log). Check for all messages around the time of import.

spelliott7 commented 5 years ago

You're thorough understanding humbled me. In review there were a few issues, primarily with the docker run command. I didn't consider you wrote that from the perspective of a Docker guru. You gave me exactly what I needed in the provided command. Thank you!

On Mon, Jan 7, 2019 at 7:33 AM Jean-Christophe notifications@github.com wrote:

It is an issue I would need some time to investigate.

I will first try to replicate it at home.

In the mean time, did you try to check the logs and see if mongo reported an error during the import? Inside the container, under /var/log/unifi you can find the file mongod.log and server.log. It would be interesting to see if you have any errors at the time of the import.

In the examples I have given in the README file, those are really only for testing. For production, you would want to use something like:

$ docker run --detach --cap-drop ALL --restart unless-stopped \ -e TZ='Europe/Berlin' \ -p 8080:8080 -p 8443:8443 -p 8843:8843 -p 10001:10001/udp \ -v ~/unifi/data:/var/lib/unifi \ -v ~/unifi/logs:/var/log/unifi \ --name unifi jcberthon/unifi

The above command will spawn the container in the background and tell the Docker daemon to monitor it and restart it automatically if it exits (see the documentation for the meaning of the different values of the restart command). At least when your container fails due to an error, Docker will restart it for you. The docker-compose.yml file in the root of this project provides good default for a production environment.

Another reason why it could failed during import is when the container would be using more RAM than allowed. I have tested the container with a limit of 768MB for a small site (1 AP + 1 Switch) and it works. It might not be sufficient for a bigger site, or during import. While importing, the Unifi software might load the file in memory (including all historical records) and import that into the DB. I have never tested an import of a big site or a small site with a big history, so I do not know how much memory it requires. The developer of the unifi application are better placed than me to tell you. If your container ran out of memory, the Linux host should have logged it inside syslog. You can check syslog by using the journalctl command (for systemd based systems) or by checking the syslog file (which could be either messages or syslog and which is usually under /var/log). Check for all messages around the time of import.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/jcberthon/unifi-docker/issues/6#issuecomment-451936013, or mute the thread https://github.com/notifications/unsubscribe-auth/AlUfnmmBG4CrUXIRdvxDWtwVCqCJs3ypks5vA0zDgaJpZM4Zo5is .