App fails to use existing database. Terminates abnormally.

[tiredofit]

App fails to use existing database. Terminates abnormally.

[bfren]

I've logged the fi issue in #54

I also had this happen though, it wiped the database (thankfully I had a two-hour old backup). So this is quite a serious bug!

[tiredofit]

Oh jeez, I am terribly sorry about this.
Fixed in https://github.com/tiredofit/docker-freescout/commit/b7a3f16988cce18c9de3fd990325dbd8875ca381 which is also tagged as 1.15.9 and should be on Docker Hub shortly.

[bfren]

Oh jeez, I am terribly sorry about this.
Fixed in https://github.com/tiredofit/docker-freescout/commit/b7a3f16988cce18c9de3fd990325dbd8875ca381 which is also tagged as 1.15.9 and should be on Docker Hub shortly.

As far as I can see this is still happening - I took a backup, updated to 1.15.9, and the same thing happened as before - tried to log in but the user didn't exist / credentials didn't match.

Is it actually emptying the database, or changing the app key perhaps?

[tiredofit]

The change in 1.15.8 was simply rotating the way that I handle the freescout cron job to poll for new messages, so I'm at a loss here for as to what could be happening with it. I'll have to get a copy of my production environment moved onto a dev server to see if I can recreate this. Problem is with my production environments I am still running the 1.12.x series as my implementation is rather large (125+ mailboxes) and I try to keep things as stable as possible.

It very well could be the APP_KEY mechanism has changed as well, it would be useful to see if the database actually still has entries in it after the upgrade or if everything has been truncated.

FWIW, this is the only area that could be destructive to the DB in my init script:

### Check to see if DB is populated
mysql -u $DB_USER -p$DB_PASS -h$DB_HOST -P$DB_PORT -e "use "$DB_NAME"; SELECT * FROM users;" > /dev/null 2>&1
if [ $? -gt 0 ]; then
    ### Perform Database Installtion Routines
    print_warn "Detected empty Database - Setting up - Please wait.."
    sleep 5
    sudo -u "${NGINX_USER}" php artisan migrate:fresh --force >/dev/null
    sudo -u "${NGINX_USER}" php artisan freescout:clear-cache >/dev/null

If that MySQL command does not execute cleanly, then it will execute the migrate:fresh command, which would clean out the database. I wonder if something has changed with the MariaDB client.

What would be useful for me is if you were willing to try it again, but this time with DEBUG_MODE=TRUE enabled. You could send me the log file privately to dave at my github handle dot ca (please strip out your mysql/mariadb password) and I can see if I can track where this is happening.

[bfren]

All done, hopefully I got your email right!

[tiredofit]

OK< I have found what was causing this. For some reason the file "assets/defaults/30-freescout" went missing from 1.15.7 to 1.15.8 When the image boots it pulls in some sane default values, specifically DB_PORT (3306). - Anyone who didn't explicitly set the DB_PORT variable became affected. The check to see if the database was populated failed because of the blank DB_PORT value, which triggered the install script to rewrite the database.

I've pulled 1.15.8 and 1.15.9 from Docker Hub entirely, and just pushed a new version 1.15.10 which reintroduces the defaults file, and also quiets down some of the install routines. Please let me know if this gets you back working.

[bfren]

Will do, just in the middle of moving house though so will be a day or two!

[mostlydev]

Thank you for this. Apparently i'm not getting notifications. Checking if it works

[mostlydev]

Looks like this has resolved it. I've left off the DB_PORT variable just to be sure.

Thank you very much for the help.

The danger for people who don't catch this is that it continues to back up empty databases, which will eventually remove legitimate copies. I think this might warrant an email to to the users.

Please feel free to close according to whatever issue closing rules you have in place.

[mostlydev]

This is still an issue. App has wiped itself two weeks in a row. It looks like some maintenance task periodically does a restart and then when it spins back up it drops the database and initializes with an empty one.

[tiredofit]

I need more information before I can act. Logs? Time of day when the db gets dumped? Image version?

[tiredofit]

Tell me as well if you have a DB_PORT variable set...

[mostlydev]

Latest currently (Freescout 1.7.13)
Don't have logs because this happened on the 29th sometime and the logs rolled over. We now have a monitor on the site so we can interrogate when it happens again. DB_PORT is not set.

[mostlydev]

We don't see much volume on this server, so we're content to let it die again to help capture the logs.

[tiredofit]

OK. Let me know when you know more. DEBUG_MODE=TRUE will help as well with an awful lot of console output. There also should be some logs in /var/log/cron/cron.log as well if you feel it is a scheduler issue.

[mostlydev]

It happened again yesterday. DB_PORT was set. DEBUG_MODE was not. I'm not sure where to look.

Did you want to ssh into the server and take a peek? Happy to provide the creds privately.

[mostlydev]

Thank you, @tiredofit! As an explanation to others, this continued on our server due to some negligence on my part.

This issue is most likely resolved.