Hi guys,

Apologies for the melodramatic title, but it is technically true.
I have a demonstration site for my Drag'n'Drop Uploads module, at http://demo.stuar.tc/dragndrop_uploads, and every so often while cron is being run my site just dies due to a malformed database.

I haven't had enough time to look into it too much myself, but it's now been down twice in two days and if it goes down when I'm at work I can't fix it until the end of the day, which is just not good.

It's possible/likely that it has something to do with using Poormanscron to trigger the cron, and I will attempt to test that as soon as I have a chance.

If you have any thoughts on this issue please let me know.

Cheers,
Deciphered.

Comments

Ela’s picture

Do you have it set up to automatically restore your site?

Deciphered’s picture

It was yes, I had to disable the functionality due to the constant deaths.

It was resetting the site back to a previous state every 6 hours as triggered by poormanscron, which I believe is likely the issue.

Ela’s picture

Yes, that would do it .. it was resetting it to whatever point it was set to do it. :)
I use this module for backups, but I don't use the automatic restores...
Glad you figured it out. :)

Deciphered’s picture

Well, I made an assumption, not figured it out. I haven't had time to actually re-enable the cron job to test the cause of the issue.

And where that the issue, it still needs to be fixed as it is part of the advertised functionality of the module.

sun’s picture

Title: Demo module kills my site :( » Automatic cron resets do not always properly reset the site
Category: support » bug

Interestingly, I also experienced _occasional_ cache table hickups on admin_menu's demo site. Only from time to time though, and almost never with the most recent module's code.

Not executing cron via Poormanscron though, so I don't believe that this is the cause. Did you already try with the latest code?

In my case, the site output was a (Drupal-generated) 404 on all pages. Until all cache* tables were flushed manually.

Deciphered’s picture

Just a quick update, I still haven't had a chance to attempt to debug, but it got to a stage where the site was going down daily and I had to disable the automatic reset functionality.

It wasn't just cache table hickups, it was more like the import to the backup database would stop midway through, you some time end up with 10 or less tables where there should be 58.

I realize that the information I've provided is not really enough to determine the cause, and I will try to make some time one of these days to do some debugging, but I just wanted to make the issue known because it is definitely critical when the site goes down daily.

Cheers,
Deciphered.

Ela’s picture

I had this problem once too... did not connect it to the module then.. but later figured out that tables were missing, after resetting my site.. The whole site was gone, only errors on pages, snd I could not figure out why.. went through hell that day! ..
I like this module a lot, use it for backups and restores when needed.. but yes, this problem happened to me too.

Ela’s picture

ok.. I just had this happen again.. I wonder if this can happen while cron is running still?
What happened:
I went to demo module to restore site manually to a snapshot created last night.
Site crashed..
Errors on pages:
Warning: Table 'XXXXXX.users' doesn't exist query: SELECT u.*, s.* FROM users u INNER JOIN sessions s ON u.uid = s.uid WHERE s.sid = '6o5ucen1q2k41c9t19f2l0s9o7' in /home/content/v/a/c/XXXXXX/html/includes/database.mysqli.inc on line 128

Warning: session_start() [function.session-start]: Cannot send session cache limiter - headers already sent (output started at /home/content/v/a/c/XXXXXX/html/includes/database.mysqli.inc:128) in /home/content/v/a/c/XXXXXX/html/includes/bootstrap.inc on line 1037

Warning: Table 'XXXXXX.variable' doesn't exist query: SELECT * FROM variable in /home/content/v/a/c/XXXXXX/html/includes/database.mysqli.inc on line 128

Warning: Table 'XXXXXX.system' doesn't exist query: SELECT name, filename, throttle FROM system WHERE type = 'module' AND status = 1 AND bootstrap = 1 ORDER BY weight ASC, filename ASC in /home/content/v/a/c/XXXXXX/html/includes/database.mysqli.inc on line 128

Warning: Cannot modify header information - headers already sent by (output started at /home/content/v/a/c/XXXXXX/html/includes/database.mysqli.inc:128) in /home/content/v/a/c/XXXXXX/html/includes/bootstrap.inc on line 636

Warning: Cannot modify header information - headers already sent by (output started at /home/content/v/a/c/XXXXXX/html/includes/database.mysqli.inc:128) in /home/content/v/a/c/XXXXXX/html/includes/bootstrap.inc on line 637

Warning: Cannot modify header information - headers already sent by (output started at /home/content/v/a/c/XXXXXX/html/includes/database.mysqli.inc:128) in /home/content/v/a/c/XXXXXX/html/includes/bootstrap.inc on line 638

Warning: Cannot modify header information - headers already sent by (output started at /home/content/v/a/c/XXXXXX/html/includes/database.mysqli.inc:128) in /home/content/v/a/c/XXXXXX/html/includes/bootstrap.inc on line 639

Warning: Table 'vac0915808564117.url_alias' doesn't exist query: SELECT COUNT(pid) FROM url_alias in /home/content/v/a/c/XXXXXX/html/includes/database.mysqli.inc on line 128

(Replaced my info with XXXXXX)

Being that this happened to me before, see here: http://drupal.org/node/665462 I first tried to go to the control panel with godaddy and First tried to use my own backup file from this module (Copied it to the folder that godaddy lets you use), that restore failed, .. so then I used their backup from yesterday, but that did not help at all... site was still broken. So i called godaddy... and they also were not able to use that back up... but got the site back for me with one of their own files from the day before.
Can backups used with this module be used for restores using different method? (like godaddy control pannel)
What other ways are there to save your site??
So twice now upon trying to restore a site, it actually crashed it....
Thank you for any thoughts or input.

sun’s picture

The SQL files generated by Demo module are almost 100% the same as dumps created by phpMyAdmin. So they can be used with whatever tool you have at hand.

However, if the restore failed after manual backup AND manual restore, then you are having an entirely different issue than the topic of this issue.

Deciphered’s picture

Agreed, I was perfectly able to restore from the demo created backup manually, it was just the automatic restore that went bad, almost as if the process was interrupted part way through.

@ela
I'd suggest creating a separate issue to keep this issue (that I desperately need to follow up on) on topic.

sun’s picture

@ela: I've unpublished your comment to keep this issue clean + focused... if you disagree, please let me know.

Ela’s picture

as you wish :) It happened when using the module, but not during automatic resets...
So I guess MY issue title would have to be "resets do not always properly reset the site" :( I felt it was related as to the extend that both issues happen with resets and in both tables are missing... I apologize for posting in the wrong place.

sun’s picture

Component: Code » Demo Reset
anni’s picture

Priority: Normal » Major

I´ve got a similar problem. After restoring (from manual backup), I get a whitescreen and nothing works.

Is there a way to fix that?

vomitHatSteve’s picture

Bit of a thread necro here, but I would consider this a critical flaw in this module.

I'm using version 6.x-1.4 of Demonstration Site, running hourly restores to a known good state.

Sometimes (I haven't seen a detectable pattern yet) when it tries to restore, arbitrary tables get deleted. Specifically, it deletes the system table. Considering that this completely bricks my Drupal install, this should probably be fixed ASAP!

gaurav.kapoor’s picture

Issue summary: View changes
Status: Active » Closed (outdated)