uberchuckie

Updated bind. Let me know. I think the latest bind version broke dig. dig was working on my system before I inadvertently updated it. (I removed the libraries that are found on the list) /usr/lib64/libjson-c.so.4 exists but not version 5. Maybe the latest version of bind added kerberos support from krb5. /usr/lib64/krb5 only contains winbind_krb5_locator.so nslookup has the same library dependency issue.

WireGuard working fine for me with PIA as well. Getting much better throughput with WireGuard than OpenVPN. I think it was CPU bound due to OpenVPN being single threaded.

@seanwalter Thanks for helping to debug. You can switch back to the latest tag as all the fixes have been applied to it.

The new version 3.0 image is working for me both upgrading from the previous image and from scratch. I've updated the latest tag. Please switch back to the latest tag if you've tested the other tags. Thanks.

Good to hear! Thanks for helping me diagnosing this problem.

@chip You can retry now with the 3.0_beta tag. Just click on "Check for Updates" to pick up the new container image.

@chip @seanwalter I think I've fixed it. I have updated the 3.0_beta tag with the fix. If everything goes well, I'll push all the updates to the latest tag. @seanwalter Please backup your data before you try it. The 3.0_beta tag contains Observium 20.9 and would perform an irreversible schema update. Thanks for your patience to help me track down this bug. The pull request for the fix is: https://github.com/charlescng/docker-containers/pull/8

The problem is related to the MariaDB 10.4 -> 10.5 upgrade. The some of the configuration that is to be rewritten in the my.cnf has moved. I'll look into fixing it when I have time.

OK, I think I know what's going on. When MariaDB first starts with the script to bootstrap itself, it's using the mysql:mysql user/group (104:106). The script changes the ownership to nobody:users (99:100) and causes the file permission issues. This has always been the behaviour and I don't know why this doesn't fail for others but fail for some. It makes sense that changing the permissions to 777 works for you. My host doesn't have user 104 and group 106 defined. Maybe this is why it's working. I'll need to think about how to fix this without breaking it for others.

@chip Can you delete everything and try the 3.0_beta image? I'm not sure why the table would be corrupted right after being created. Edit the container definition and change the Repository from uberchuckie/observium to uberchuckie/observium:3.0_beta. The image contains Observium 20.9, MariaDB 10.5.5 and a change to the run script to always update the file permissions.

@seanwalter I've just pushed the tag for 3.0_beta. This includes Observium CE 20.9.10731, MariaDB 10.5.5 and the latest apt packages. It shouldn't change how the container works on your system but you can always give it a try. It works fine for me both creating a database from scratch and updating from the 19.8.1 schema.

Another thing to look into is what Squid had mentioned. Do you have a cache drive? If so, is the volume mount on /mnt/user/appdata or /mnt/cache/appdata?

@seanwalter MariaDB shouldn't be using /var/log/mysql for its log files or /var/lib/mysql for its data files. It's in the container's ephemeral disk and does not persist between container instances. It's supposed to use the /config/ volume mount. MariaDB is started with /usr/bin/mysqld_safe --skip-syslog --datadir='/config/databases' from the runit service, MariaDB should be using the volume mount for its data. It's weird that a brand new container instance works for you but not @chip. This has got to be something related to file permission issues or something along the line. It's hard for me to debug this without access to a broken system.

@chip The "aria_log_control" should be created in the /config/database volume. /etc/service/mariadb/run is the runit script to start MariaDB in the container. It should be starting MariaDB with I'm not sure why it's using /var/lib/mysql in your case. EDIT: Ah, you were running it from the command line. Can you start from scratch and post up the error in the MariaDB log file? The log file should be '/config/databases/8ffb5f7097ea.err'

@chip OK, I missed this earlier: 2020-09-23 15:28:02 0 [ERROR] mysqld: Can't create/write to file '/var/lib/mysql/aria_log_control' (Errcode: 13 "Permission denied") 2020-09-23 15:28:02 0 [ERROR] mysqld: Got error 'Can't create file' when trying to use aria control file '/var/lib/mysql/aria_log_control' I'll take a look as to why it works on my server but not on yours.

@chip Is this an upgrade from a previous image or are you trying to get it to run from scratch? Running it manually without the "--datadir='/config/databases'" flag doesn't use the same data location and thus the user "observium" wouldn't be created. It's interesting that running it manually does seem to start which could point to a permission issue with the /config volume mount.

If you have deleted the log files, I'm not sure if reverting to MariaDB 10.4 would help. What are the MariaDB errors now? Can you post the log file to show why it's not starting?

Having the MariaDB log file is useful. I'm not sure if the problem is the same as the others are having but the symptoms are the same where MariaDB is not starting. The problem here is the redo log is preventing the MariaDB to upgrade from 10.4 to 10.5. You can try reverting to image tag 2.0.2, shutdown and see if the redo gets processed properly then move the latest again. The other thing you can try is to just delete the /config/databases/ib_logfile* before trying to start the container. You may potentially lose transactions that were not committed but that's probably fine.

Nothing jumps out at me as the problem right now. Maybe it's failing to start because it can't create the <docker id>.err file? I haven't been able to reproduce the problem on my server.

Nothing looks out of the ordinary. It's strange that the database log file doesn't exist. Maybe it can't create it and that's why it's failing? What version of unRAID are you running? It looks like MariaDB is running fine during the schema creation but the service won't start after it shuts down and restarted. Can you run /usr/bin/mysqld_safe --skip-syslog --datadir='/config/databases' in the container console? I can't reproduce this problem on my server.

@Fiala06 MariaDB appears to be in a restart loop. Can you post the /config/databases/9ac22bf8d797.err log to show why it's failing to start?

@seanwalter Can you post the contents of the /config/databases/observium.err log file? That will tell us why MariaDB is not starting.

@seanwalter I pushed a change to always fix up the permissions before staring MariaDB. It didn't break anything for me and the permissions are set to nobody with 755 permissions. Backup your database and give the dev tagged image a try? I'll push 2.1.2 if it fixes it for you.

This should be safe to run as it's already the last step of the MariaDB script when it's creating a new database. I'll test it out when I have time.

It looks like file permission problems. Here are my file permissions. Creating the database files from scratch, I see the following permissions Can you post your config permissions?