uberchuckie

@kimocal The embedded MariaDB service was stuck in a restart loop. The /config/databases/ea65e1ef1086.err file should show why. I've had this error once before. MariaDB couldn't read the InnoDB files for me. Restoring from backups or creating the database from scratch resolved the issue for me. This image doesn't need privileged access and works without it.

Check the nginx log and see what the error is. Did you define an upstream pool for observium? Try using the IP address instead for the proxy pass URL?

I don't think alerts are supported in the Community Edition.

Mine is 438MB with around 4 years of data from one device.

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.