watchdog t() strings not upgraded from D5 to D6
mikeytown2 - January 21, 2009 - 00:32
| Project: | DB Maintenance |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Jump to:
Description
After installing this Module, cron fails; and after disabling it, Cron is still in a failed state.
Attempting to re-run cron while it is already running.
strtr() [<a href='function.strtr'>function.strtr</a>]: The second argument is not an array in /home/content/m/c/a/mcarper/html/includes/common.inc on line 891.
Invalid argument supplied for foreach() in /home/content/m/c/a/mcarper/html/includes/common.inc on line 874.Ran it - optimized all tables.
Then set it to opt & backup DB on every cron, and backup files weekly, with an email notification.
Then Ran Cron and poof, error.
Now I can't get cron out of already running state.
#1
K after restoring the DB and going at it again, this time with all the frequency settings at never, I got it to do a cron successfully after optimizing every table.
Side note, this was the only repair on the DB that happened
Success: REPAIR table ___.users, type: status, message: OKSo for now I will continue to use Backup and Migrate as my DB backup and FTP for file backup; cool thing is, my DB is now optimized.
EDIT:
forgot to say that I still get the 2 Errors in the Original Post.
#2
In the future, to clear stuck crons, you can use the devel module's edit variable option to delete drupal's internal "cron_semaphore" variable to unstick it or from the database sql command:
USE Name_Of_Your_Drupal_Database;DELETE FROM variable WHERE name="cron_semaphore";
or http://www.digitaledgesw.com/node/21
#3
Thanks for the info. This does indeed free up the stuck cron job (tho' I also have to delete the "cron_last" variable as well as "cron_semaphore" to get cron back again).
What really needs to be answered is why is DB Maintenance causing cron to get stuck.
After discovering the same problem on my site as the original poster describes I freed up cron and then tried DB Maintenance again.
Cron fails again.
Any help would be greatly appreciated.
I've been using DB Maintenance for a while and would love to see the 2.0 version released. . .
Thanks
#4
I get the same errors....Without the first line the "Attempting to re-run cron while it is already running." does not come up for me so may be unrelated.I get the following error repeated 7 times. It comes and goes and is seemily in sync with Cron jobs but I have yet had no errors stating issues with the cron jobs.
I don't even run DBmaintenance btw. Unless it is part of the D6 core and I am just not aware so possibly the issue lies elsewhere more deeply rooted???
strtr() [function.strtr]: The second argument is not an array in /home/content/*/*/*/**********/html/includes/common.inc on line 891.
Invalid argument supplied for foreach() in /home/content/*/*/*/**********/html/includes/common.inc on line 874.
Is there Anyone who can shed some light on this please?
#5
I don't think this discussion is really continuing as a db_maintenance but so much as figuring out why your cron is running long.
#6
Running this http://drupal.org/node/356959#comment-1196701 points back to this module and this error
type: db_maintenancemessage: Failure: OPTIMIZE table drupal_db.users type: warning, message: Found row where the auto_increment column has the value 0
COUNT(*): 1
strtr() [<a href='function.strtr'>function.strtr</a>]: The second argument is not an array in /home/content/m/c/a/mcarper/html/includes/common.inc on line 891.Invalid argument supplied for foreach() in /home/content/m/c/a/mcarper/html/includes/common.inc on line 874.
#7
Are you sure you're running HEAD? That second error should have been fixed a couple days ago...
#8
didn't see that it was set to head, running 2.0-beta1
#9
Now that that's clear, strtr bug has been fixed in http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/db_maintena...
There's some discussion on optimizing users on http://drupal.org/node/254441, though unless you're deleting lots of users all the time, optimizing users is probably a pointless thing to do anyway and you can just unselect it. There's also some discussion on the mysql commentable docs that some mysql versions might be more picky about a 0 index in an auto_increment field than others.
#10
#11
Automatically closed -- issue fixed for 2 weeks with no activity.