Support ⇒ Troubleshootings ⇒ Sessions Delete Loop in 9.4.0.0 ⇒ Community Forums ⇒ CPG Dragonfly™ CMS
Forum IndexTroubleshootings

Sessions Delete Loop in 9.4.0.0 Reply to topic


Reporting here as there is no possibility of reporting version 9.4 bugs in the Bug Reporting system (?!?!? - Even if you want to decline to fix them, surely leaving them unreported hinders knowledge among users, and may suppress a bug which applies to v10 too?)

Summary: v9.4.0.0 went into a tight loop (not possible to login via web from user or admin side due to lack of response / blank screen) reporting an SQL Error "While executing query "DELETE FROM cms_session WHERE time" (sic)

Details: Host took down shared MySQL server due to load spike (not any of my sites), and restored immediately. Another of my sites recovered normally with just a few sever gone away messages, but one started these DELETE reports and continued (for hours) with several thousands of emails (2 to 6 per minute). Reports came from all modules as it tried to clear the cms_session file (on each web request?).

Attempts to access db via phpMyAdmin were successful if a little slow, but access to cms_session displayed a "Table 'cms_session' is marked as crashed and last (automatic?) repair failed"

Had to get the site back up asap as it - inevitably - occurred on a critical Sale day with client on-site with customers who were trying to access the website, so capturing further diagnostics was not possible.

Tried clearing cache, which seemed to have no effect, and then emptying the cms_session file, which worked.

Could/Should the error be dropped after a suitable count in order to service the web interface, or is there no way to continue with a problem in cms_session file?

Anything which can be done to prevent a possible recurrence?

Note also that the error message seems wrong with 'time' incomplete and the rest of the usual email message format apparently missing.

Any advice gratefully received.

[ Note I felt the empty command was appropriate as no users have access to site, only admins, who were not logged in, so every access was a visitor. ]

Pro_News CM™ - Content Management for Dragonfly CMS™

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Linux / 1.3.39 - 2.4.9 / 5.5.42 - 5.6.16 / 5.4.37 - 5.5.11 / 9.4

Last edited by layingback on Thu Mar 31, 2016 10:11 am; edited 1 time in total


What should be done when the database has crashed?

v9 you get spammed with e-mail when there's something wrong so you know it.

v10 will not e-mail you so you will never know unless you visit your own website.
v10 does store all errors in a file log though, but then you must check your FTP frequently.

Both ways are annoying in case of errors.

A solution might be to disable the whole website on a single error.
But what if that error has nothing to do with a corrupt database?

It is a tough question that can't be solved that easy.
Should think hard how to get this solved.

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Fedora 25 / Apache 2.4.27 / MariaDB 10.1.26 / PHP 7.1.10 / Mercurial


Idea: what about logging to a file and send the file once per hour/day/week?

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Fedora 25 / Apache 2.4.27 / MariaDB 10.1.26 / PHP 7.1.10 / Mercurial

All times are UTC


Jump to: