unRAID Deployment #13
Comments
|
olympia: |
|
@prsmith777 the docker-compose.yml file provides the overview, but what you need to do:
|
|
Awesome thank you. Got it going EDIT: Not connecting to database.... getting this error: Database connection test failed: Error: getaddrinfo ENOTFOUND db |
I'll add some more configuration ability to the dashboard for things like date filtering. The vehicle description is a bit of a leftover because the AI doesn't have a great way to do this currently, but I do plan to allow the user to manually enter these details. For now, you could just put it in the notes if you needed to. The other addition that I am prioritizing is the ability to correct plate recognitions in the live feed page. This will allow you to prevent your plate database from having 5 different variations of the same plate as a result of OCR misreads. Thank you for sharing your Unraid instructions. I was going to make a docs directory to link to other more specific guides like this. If you would like credit, please make a pull request and put it in /docs/unraid.md. I can also do it myself if you prefer. |
There are a few things you can check here.
|
Super, many thanks for all these!
OK, but let's wait first if the instructions can get the first one go :) @prsmith777 Did you follow the order of the instructions for postgres installation? If you started postgres docker without configuring the schema path first, then the alpr database hasn't got generated. Also, how did you set the network for the dockers? Did you configure "bridge' networks or you set specific IP addresses for your dockers? |
|
Thanks for both your help. I added DBHOST: 192.168.0.250:3000 and still no luck I did the configuration in order as stated. I set network to bridge There are no conflicts using port 5432 Here is postgres log: 2024-11-25 14:26:40.025 MST [1] LOG: listening on IPv4 address "0.0.0.0", port 5432 The database cluster will be initialized with locale "en_US.utf8". Data page checksums are disabled. fixing permissions on existing directory /var/lib/postgresql/data ... ok Success. You can now start the database server using: waiting for server to start....2024-11-25 14:07:36.418 MST [49] LOG: starting PostgreSQL 13.18 (Debian 13.18-1.pgdg120+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14) 12.2.0, 64-bit /usr/local/bin/docker-entrypoint.sh: ignoring /docker-entrypoint-initdb.d/ 2024-11-25 14:07:36.544 MST [49] LOG: received fast shutdown request PostgreSQL init process complete; ready for start up. PostgreSQL Database directory appears to contain a database; Skipping initialization PostgreSQL Database directory appears to contain a database; Skipping initialization |
|
It's not possible to tell from the log if the alpr database has created successfully or not. go to postgres docker console and type:
What do you get there? |
psql -d postgres -U postgres -WPassword: postgres=# \dt |
|
That's not OK. ALPR database is not there.
|
|
followed those steps and getting same result: postgres=# \dt |
|
Then probably something is not OK with your docker config, particularly the reference the the schema.sql. |
|
|
|
3000 is not the right port. Notice that it says the database is listening on 5432. 3000 is for the app itself. You will want to set the database host to :5432 or if you exposed a different outside port for the database set it to that. |
|
Still not working |
Yes, that's indeed incorrect too, but his database hasn't been generated correctly. First we would need to get that resolved. "Unfortunately" the docker config is correct, so I am not sure what the issue is. Can you delete the content of the data subdir again, then run the docker and then post the the docker logs? |
|
Here is the log after deleting data subdir and starting docker back up: 2024-11-25 15:25:18.003 MST [1] LOG: starting PostgreSQL 13.18 (Debian 13.18-1.pgdg120+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14) 12.2.0, 64-bit 2024-11-25 15:25:17.851 MST [48] LOG: received fast shutdown request PostgreSQL init process complete; ready for start up. PostgreSQL Database directory appears to contain a database; Skipping initialization The files belonging to this database system will be owned by user "postgres". The database cluster will be initialized with locale "en_US.utf8". Data page checksums are disabled. fixing permissions on existing directory /var/lib/postgresql/data ... ok Success. You can now start the database server using: waiting for server to start....2024-11-25 15:48:28.786 MST [48] LOG: starting PostgreSQL 13.18 (Debian 13.18-1.pgdg120+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14) 12.2.0, 64-bit /usr/local/bin/docker-entrypoint.sh: ignoring /docker-entrypoint-initdb.d/ waiting for server to shut down...2024-11-25 15:48:28.909 MST [48] LOG: received fast shutdown request PostgreSQL init process complete; ready for start up. |
|
This line in the log doesn't seem right: /usr/local/bin/docker-entrypoint.sh: ignoring /docker-entrypoint-initdb.d/ |
|
The log file indicates the presence of an existing database with the message: I don't see how this can be if there is nothing in the data directory. |
|
perhaps the issue because I first tried setting things up using docker compose manager. maybe that original database is still in there confusing things. Is there a way to manually delete all databases and try again? |
|
By deleting the data dir, everything should be purged. shrug |
|
directory global and gb_wal aren't deleting. I thought they were Trying krusader to delete |
|
still same result \dt |
|
how you delete the data dir? Using SMB or terminal? |
|
Deleting using Unraid file manager |
|
This line in the log says: /usr/local/bin/docker-entrypoint.sh: ignoring /docker-entrypoint-initdb.d/ It is ignoring this entrypoint so maybe it cant get to the schema.sql file. |
The log suggests that it is ignoring initialization, because it finds and existing database. I am running out of ideas... Can you delete the data folder once again (make sure the docker is stopped first). share what you see there. and then ls -la /mnt/user/appdata/postgres13/schema share what you see there. |
|
root@Storinator1:# ls -la /mnt/user/appdata/postgres13 |
|
so where is the schema.sql? :) |
|
well it was there. I re added it |
|
root@Storinator1:~ # ls -la /mnt/user/appdata/postgres13 |
|
OK, cool, let's delete the entire data folder, so the folder as well, then start the docker |
|
psql -d postgres -U postgres -W postgres=# \dt |
|
and the docker logs? |
|
--auth-local and --auth-host, the next time you run initdb. Success. You can now start the database server using: waiting for server to start....2024-11-25 16:41:38.554 MST [48] LOG: starting PostgreSQL 13.18 (Debian 13.18-1.pgdg120+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14) 12.2.0, 64-bit /usr/local/bin/docker-entrypoint.sh: ignoring /docker-entrypoint-initdb.d/ 2024-11-25 16:41:38.678 MST [48] LOG: received fast shutdown request PostgreSQL init process complete; ready for start up. The files belonging to this database system will be owned by user "postgres". The database cluster will be initialized with locale "en_US.utf8". Data page checksums are disabled. fixing permissions on existing directory /var/lib/postgresql/data ... ok Success. You can now start the database server using: waiting for server to start....2024-11-25 16:46:47.003 MST [49] LOG: starting PostgreSQL 13.18 (Debian 13.18-1.pgdg120+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14) 12.2.0, 64-bit /usr/local/bin/docker-entrypoint.sh: ignoring /docker-entrypoint-initdb.d/ 2024-11-25 16:46:47.208 MST [49] LOG: received fast shutdown request PostgreSQL init process complete; ready for start up. |
|
IT looks like now it doesn't find an existing db, yet ignoring the entrypoint: No ideas, and it's 1am past here. |
|
Interestingly, the whole db already exists ignoring entrypoint thing does usually show up and things still work in most cases. Also, if the database exists and has a schema created, whether or not it is actually correct, that means that the connection issue probably isn't because of that. I'd double check that your schema.sql isn't empty and was correctly obtained. These shutdowns in the logs are you right? The container isn't exiting? The only other thing I could think of that might cause this is the config directory not working correctly on unraid. While it shouldn't be necessary normally to manually set an environment variable for the db host since you can change it in the settings, maybe try it. Note that the variable is actually called DB_HOST, not DBHOST. I would try to deploy the postgres container and see if you can connect to it on its own with something like pgadmin. This will help isolate the issue. |
|
Guys, thank you both for your help yesterday. I appreciate the effort and I have learned a lot. It seems getting this working with my UnRaid is a lost cause.... but then I had a thought.... I decided to try a different approach.. I spun up a Linux VM in UnRaid and set up docker. Then I set up ALPR and it is working. One thing I noticed is that the postgres container wasn't starting on reboot of Linux VM, so I added Not sure if this is the proper approach, but it seems to work. |
|
Glad you had it working. Running a VM is a perfectly proper approach; it just seems an unnecessary burden on the server. I really don't know why it is not working for your. |
Hi @olympia , I followed all your steps above with running postgresql13 as a separate container then running alpr-dashboard via ADD CONTAINER in unraid. It's kind of working though getting some errors. Here are all the logs I have. Postgresql13 logs after wiping out data and restarting container: postgresql13 console comands alpr-dashboard logs After I "Trigger now" on the LPR camera there is some action in the alpr logs: Here are screenshots of the container configs:
I have verified that the API is correct. Here are the ALPR Settings
BI Camera Alert Settings:
Any insight would be appreciated. Thanks in advance. |
|
I think this is because schema.sql hasn't been updated to create the new devmgmt column in the table, so it doesn't get generated when you run postgres_db for the first time. Not sure why, maybe the new install scripts are running the migrations.sql right away? @algertc can probably clarify on this. To workaround this, you would need to download and mount migrations.sql on the same way as schema.sql, then open postgres docker console and run |
@olympia That seems to have fixed it.
I also added the images path to alpr-dashboard container as I was comparing against the docker-compose.yml |
|
Great, glad it worked out for you!
Yes, this is indeed needed as well. This new folder requirement is pretty recent, hence the steps above doesn't include this yet. |
All good. Thanks again for your feedback. |
Hi Charlie,
I installed and set this up on unRAID (without docker compose) a couple of days ago.
I don't have lots of data yet, but looking absolutely amazing. Thank you very much for creating this!
Would it be possible to have a selector at the top plates to chose from last 24 hours, last week, last month, last year or maybe custom dates?
...and I am wondering about vehicle description on the live feed: is this configurable somewhere, or is this a dead leftover from some initial plan? :)
Many thanks again!
The text was updated successfully, but these errors were encountered: