jeromek has asked for the wisdom of the Perl Monks concerning the following question:

Hi All,

I installed an application based on Dancer at the beginning of the week and notice that the connection to the mysql DB got lost after a few days of running.

Logs report crashed: DBI connect('database=xxxxx','xxxxx',...) failed: Access denied for user 'xxx'@'localhost' (using password: YES)

The authentication method is user/password and they are of course correct. Mysql was fine at the time the application was crashing and I could connect with mysql client using the application credentials.
Restarting the application solved the problem.
The application is deployed with plask:
sudo -u www-data /usr/local/bin/plackup -E production -s Starman --workers=1 -l /tmp/plack.sock -a bin/app.pl & I am using the Dancer::Database plugin with connection_check_threshold: 10

Has anybody experienced this problem ? What could cause an access denied ? According to mysql doc, this message means wrong password. Could the in-memory password just get lost ? Weird.

Replies are listed 'Best First'.
Re: Dancer app losing DB connection
by Anonymous Monk on Aug 15, 2014 at 06:49 UTC

    Could the in-memory password just get lost ?

    Unlikely, but, what versions do you have? perl -MDevel::ModuleDumper yourstuff.pl

     

    rm -rf goners
      >> Dancer 1.3126 server 3561 listening on http://0.0.0.0:3000
      >> Dancer::Plugin::FlashMessage (0.314)
      >> Dancer::Plugin::Passphrase (2.0.1)
      >> Dancer::Plugin::Ajax (1.00)
      >> Dancer::Plugin::Database::Core (0.06)
      >> Dancer::Plugin::Database::Core::Handle (0.02)
      >> Dancer::Plugin::Database (2.09)

      Running on Ubuntu 14.04, mysql 5.5.37
Re: Dancer app losing DB connection
by locked_user sundialsvc4 (Abbot) on Aug 15, 2014 at 13:08 UTC

    Actually, database connections can drop for any reason ... inactivity, server restarts, sunspots ...

    So, what you need to be prepared to do, in your code, is to check the connection and to re-establish it at any time that you find it to have dropped.   This is true for any presistent server of any sort.

      The problem is not that the connection dropped. In case of a bad connection handle, the database plugin tries to open a new connection. At this point it does a DBI connect which fails for authentication reasons.

        Exactly ... and this is the step that you have to intervene:   if the connection-handle is bad, it basically means that the connection has dropped on one side or the other.   The plugin will attempt to re-establish the connection and you must see to it that it does so correctly.   If the credentials are still known-good, it’s not actually “for authentication reasons,” even though it may present itself that way.   A check of both the database and the web-server logs would be a good place to start sleuthing.   Even if for whatever reason (SQL server down, etc.) the connection truly can’t be re-established now, your Dancer app still must manage to do the right thing, or at least a graceful thing.

        This is a common issue with long-running persistent processing of any sort, and the symptoms presented definitely can be red-herrings.   Since you know that the credentials you have available to you are good, then you know that the message ... isn’.t.   If you chase the wrong presumption, you’re chasing a rabbit.   (Been there, etc.)

Re: Dancer app losing DB connection
by Anonymous Monk on Aug 16, 2014 at 01:36 UTC

    Hi,

    Just a guess, could ( some of ) the connection info be going out of scope at some point?

    J.C.

      Just a guess, could ( some of ) the connection info be going out of scope at some point?

      Also unlikely :)

      Although, cranking up DBI trace level and waiting for this to happen again might reveal more

      I think its a socket issue , the os manages sockets, they could get stale/deadlocked/whatever, and then the DBD erroneously reports access denied (maybe its a socket creation access denied)...

      More diagnostics to really figure out whats going on

      scheduled reboot (cron?) to void the issue :)

        That would make some sense. If the connection info was going out of scope, why only the password (since user and dbname were fine)?
        Debugging this is going to be difficult I think...
A reply falls below the community's threshold of quality. You may see it by logging in.