uberchuckie

The database hasn't been created yet. Did you stop the container before deleting the appdata volume for observium?

Try deleting your observium directory under the appdata volume mount and start the container again. Let the database initialization script run to its completion.

I took a look at this... I ran /opt/observium/poller.php -d and saw this: ##### Timezones info ##### o Date Tuesday, 10-Dec-19 21:08:21 EST o PHP -05:00 o MySQL -05:00 This looks like it's correct and PHP and MySQL have matching time offset. root@c3b53bf2ea0d:/opt/observium# mysql -u observium -p observium Enter password: Reading table information for completion of table and column names You can turn off this feature to get a quicker startup with -A Welcome to the MariaDB monitor. Commands end with ; or \g. Your MariaDB connection id is 16 Server version: 10.4.8-MariaDB-1:10.4.8+maria~bionic-log mariadb.org binary distribution Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others. Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. MariaDB [observium]> select now(); +---------------------+ | now() | +---------------------+ | 2019-12-10 21:11:56 | +---------------------+ 1 row in set (0.000 sec) MariaDB [observium]> This is also showing the correct time. I even tried adding "default-time-zone='-05:00'" to "/etc/mysql/my.cnf" and restarting the database and that didn't make any difference. The graphs are still in UTC. I'm not sure what's the problem at this point.

I tried both unRAID 6.8.0-rc9 and 6.8.0. The latest image works fine so I've push the beta tag to be the latest tag as well. I've been using the image since September and had not run into any issues.

Looks like the app is not respecting the timezone set in the environment. I'll see if I have time to take a look.

Can you post the log file?

I've gotten Observium CE 19.8.1 working. I've also upgraded the image to MariaDB 10.4.8. I ran into a possible unRAID bug with it but moving from 6.7.2 to 6.7.3-rc4 appears to have fixed it. I'll push a beta image for people to try and I'll write up instructions on the upgrade process.

I’ll see if I have time this weekend to build a new image and make sure the schema upgrade works or not. Sent from my iPhone using Tapatalk

Unfortunately, I haven't gotten around to it.

Ah, no. You still need to make changes like https://docs.observium.org/device_linux/. I'll take a look when I have time.

I took a quick look and I think I know what happened to your attempt. I am assuming that you did something similar to The Observium docs page isn't loading for me right now. When you copy the files, you have to copy them to the host, not within the container. xinetd needs to be running on the unRAID server itself (which you've already installed with nerdtools). I'll try to get this working on my server when I have time. I don't think there are any changes to the Observium image itself.

Ok, I see what you’re asking for. Do you have a sample MIB you want me to try get working? Sent from my iPhone using Tapatalk

Ok. I’ll take a look when I have a chance. Sent from my iPhone using Tapatalk

This is a product question where I think you'll be better served by their community forum.

Try: Stop the container, delete the observium directory in your appdata directory and start the container again. My guess is that the database initialization didn't run to completion before it was killed. Hard to say without seeing the entire log.

For some reason, the database schema initialization failed. I'll see if I can reproduce it. Stop the container, delete the observium directory in your appdata directory and start the container again. EDIT: I tried to reproduce the problem by starting the docker container with a /config volume mapping pointing to an empty directory. The database initialization worked for me.

I don't think it's possible. I assume you set the IP via the custom br0 network. I see "-e 'TCP_PORT_8668'='80'" in the docker run command line but it doesn't work.

I’ll look at the log this weekend and also see if I can reproduce the problem. Sent from my iPhone using Tapatalk

The container was killed while it was setting up the database. Delete the observium directory, start the container and let the setup script run to its completion. Sent from my iPhone using Tapatalk

This is a new setup? The logs shows there already was a configuration in in the config volume. > Using existing PHP database config file. Try deleting the observium directory in your appdata directory and start the container again. I don't think the database schema or the users were created properly.

I've pushed a new image where Observium's discovery.php script is now ran with the debug flag. If other users have problems with discovery script, I'll have a better idea what went wrong.

I actually saw your first post before you edited it. The last line of the log file shows that the database schema creation did not complete. Either something went wrong or it was still initializing the database. 10 minutes is a really long time. On the first run, it should show something like: What kind of hardware are you running? I think if the container is killed before the database initialization completes, subsequent restarts won't run the first run script again because the database has already been initialized. I think the first run script can be improved to pick up where it left off.

Can you delete your appdata files for observium, restart the container and post the logs? I can't reproduce the problem on my setup.

I just created a test container from scratch. The UI does come up but for the first run, it takes a minute or two to initialize the database. If you tried to logon right away, it won't work, and that's what people are seeing I think. Here is my log file from the test container:

Try stopping observium, delete the observium appdata directory and restart. It should recreate the database from scratch.