I have a Drupal cron job (4.7) that crashes the web server--just hangs but never returns a specific error message; if I let it run, it just churns. I've let it go for five minutes before finally shutting it down. Its hanging brings down the whole shooting match. The logs tell me only that a segmentation fault occurred.
Very possibly related, whenever I try to do any administration related to the user table--for instance, call up the troll module admin pages--the site hangs similarly. This is a busy site with nearly 7500 registered users in the table. How many users are too many users? I experience a similar but not nearly as dire slowdown on another site on the same box with more than 5500 registered users; calling up admin pages with users on it takes a bit but does complete, and its cron job completes in maybe 10 seconds.
I just recently upgraded both sites to 4.7.x from 4.6. Anything anyone could tell me would be useful. Thanks.
Lynn
------ Mama, homeschooler, writer, activist, spinner & knitter http://www.siprelle.com
NOTICE: The National Security Agency may have read this email without warning, warrant, or notice.
Quoting Grandmother Spider gs@grandmother-spider.com:
I have a Drupal cron job (4.7) that crashes the web server--just hangs but never returns a specific error message; if I let it run, it just churns. I've let it go for five minutes before finally shutting it down. Its hanging brings down the whole shooting match. The logs tell me only that a segmentation fault occurred.
Which logs? Does it say what is having the segmentation fault? Since Drupal is using interpreted code your issue isn't directly related to Drupal but to the third party applications it uses. Contact me off list if you feel you need to.
Earnie
I have a Drupal cron job (4.7) that crashes the web server--just hangs but never returns a specific error message; if I let it run, it just churns. I've let it go for five minutes before finally shutting it down. Its hanging brings down the whole shooting match. The logs tell me only that a segmentation fault occurred.
Which logs?
Apache.
Does it say what is having the segmentation fault?
Sadly, no, other than citing a child process. But I did see watchdog had a HUGE number of "Invalid argument supplied for foreach() " errors for taxonomy.module. So I dug through drupal.org and discovered this:
...a bug in taxonomy.module that has not fully been fixed in the 4.7.6 release. I used the suggested changes, the "invalid" arguments stopped, and eventually the cron job now after about four minutes throws an "out of memory" error as it tries to work through search.module's cron. My php.ini is set to 64M.
Thanks.
Lynn
------ Mama, homeschooler, writer, activist, spinner & knitter http://www.siprelle.com
NOTICE: The National Security Agency may have read this email without warning, warrant, or notice.
Quoting Grandmother Spider gs@grandmother-spider.com:
...a bug in taxonomy.module that has not fully been fixed in the 4.7.6 release. I used the suggested changes, the "invalid" arguments stopped, and eventually the cron job now after about four minutes throws an "out of memory" error as it tries to work through search.module's cron. My php.ini is set to 64M.
You can increase the memory_limit in the .htaccess file. Add the following line at the bottom of the file to see if it helps.
php_value memory_limit 128M
Earnie
You can increase the memory_limit in the .htaccess file. Add the following line at the bottom of the file to see if it helps.
php_value memory_limit 128M
Is that wise?
BTW, when I ran the cron job by hand this morning it didn't throw the memory error; it hasn't run successfully in some time, so perhaps it was just backlogged?
Thanks everyone for the help.
Lynn S.
------ Mama, homeschooler, writer, activist, spinner & knitter http://www.siprelle.com
NOTICE: The National Security Agency may have read this email without warning, warrant, or notice.
Op donderdag 22 februari 2007 02:22, schreef Grandmother Spider:
php_value memory_limit 128M
Is that wise?
No. That is not solving the problem, its only hiding the consequences of the problem.
My advice: iterate trough the contributions: statr with none, see if the problem occurs, switch one (or two) on, see again etc. A lot of work.
If you are a bit more PHP savvy, i'd advice to read trough the code. I see several modules wich I refuse to deploy on my hosting system / servers for reasons ranging from 'very ugly code' to 'badly designed interfaces'. It would really not surprise me to find that several modules simlpy load ALL users from the database and then walk trough them in php o_O. You see this kind of mistakes a lot in contribs. Don't think that because Drpal is well coded, the people that use it are good coders too.
Bèr
Lynn,
You mentioned it ran out of memory in the search module. Perhaps a back log of nodes to be indexed is contributing to the problem. You can configure the number of nodes it will try to index in one cron run at admin->settings->search under the indexing throttle setting. Perhaps a smaller number there would help.
Just a suggestion. Good luck.
..chrisxj
You mentioned it ran out of memory in the search module. Perhaps a back log of nodes to be indexed is contributing to the problem. You can configure the number of nodes it will try to index in one cron run at admin->settings->search under the indexing throttle setting. Perhaps a smaller number there would help.
I think this was indeed the problem, because the cron job hadn't finished in weeks and it now no longer throws the memory error. As I said, this is a busy community site with a LOT of posting going on.
Thanks.
Lynn S.
------ Mama, homeschooler, writer, activist, spinner & knitter http://www.siprelle.com
NOTICE: The National Security Agency may have read this email without warning, warrant, or notice.
Quoting Bèr Kessels ber@webschuur.com:
Op donderdag 22 februari 2007 02:22, schreef Grandmother Spider:
php_value memory_limit 128M
Is that wise?
No. That is not solving the problem, its only hiding the consequences of the problem.
But can be useful to get beyond the immediate issue while you investigate
My advice: iterate trough the contributions: statr with none, see if the problem occurs, switch one (or two) on, see again etc. A lot of work.
Earnie
If you are a bit more PHP savvy, i'd advice to read trough the code. I see several modules wich I refuse to deploy on my hosting system / servers for reasons ranging from 'very ugly code' to 'badly designed interfaces'. It would really not surprise me to find that several modules simlpy load ALL users from the database and then walk trough them in php o_O. You see this kind of mistakes a lot in contribs. Don't think that because Drpal is well coded, the people that use it are good coders too.
Oh, believe me, I'm aware of it. :)
I do know enough PHP, so I'm going to walk through troll (which I suspect is the issue--and I have to have it on both of these sites, especially Hipmama which attracts trolls like you wouldn't believe) and inactive_user. I'm also going to dig through cvs for updates.
Lynn S.
------ Mama, homeschooler, writer, activist, spinner & knitter http://www.siprelle.com
NOTICE: The National Security Agency may have read this email without warning, warrant, or notice.
Op dinsdag 20 februari 2007 23:48, schreef Grandmother Spider:
This is a busy site with nearly 7500 registered users in the table. How many users are too many users?
I sounds you have a badly coded module somewhere. Could you provide us with a list of contributed modules?
Bèr
This is a busy site with nearly 7500 registered users in the table. How many users are too many users?
I sounds you have a badly coded module somewhere. Could you provide us with a list of contributed modules?
Surely:
adsense autotimezone bookmark_us buddylist commentcloser comment_mover comment_notify ed_readmore forward gsitemap inactive_user notify print privatemsg recipe service_links smileys switch_theme syndication tagadelic taxonomy_dhtml troll urlfilter weblinks
When I try to access troll's admin pages, it hangs; everything else seems to be fine.
Thank you, Lynn
------ Mama, homeschooler, writer, activist, spinner & knitter http://www.siprelle.com
NOTICE: The National Security Agency may have read this email without warning, warrant, or notice.
All,
Firstly, thank you much for all the support you dole out over the months.
My trouble is that after a while, the node_access table has stopped being updated when new nodes are created. Usually the nid is entered, with realm = all and 'grant_view' = 1. This lets all users who have the 'access content' permission actually see the node when it is published.
But without the entries there, anon users can't see anything.
I recented used the Taxonomy Access module, but then inactivated and uninstalled if from my Drupal 5 site. Could it still be causing a problem? Can a server be caching some of the old PHP code somehow.
Thank you for your help.
Greg
Greg Holsclaw wrote:
All,
Firstly, thank you much for all the support you dole out over the months.
My trouble is that after a while, the node_access table has stopped being updated when new nodes are created. Usually the nid is entered, with realm = all and 'grant_view' = 1. This lets all users who have the 'access content' permission actually see the node when it is published.
But without the entries there, anon users can't see anything.
Ordinarily if you have no node access related modules installed, there is a single record for the realm 'all'. Not one per node.
I recented used the Taxonomy Access module, but then inactivated and uninstalled if from my Drupal 5 site. Could it still be causing a problem? Can a server be caching some of the old PHP code somehow.
It wouldn't surprise me if taxonomy access isn't playing nice with the new node access system the way it needs to, and it may not have told Drupal to rebuild the node access table properly when it was disabled.
Visit admin >> content management >> post settings
There is a button to rebuild your node access permissions table. Click that and your node_access database should be restored.
Worked perfectly. Thank you for the really fast, and correct information.
Greg
-----Original Message----- From: support-bounces@drupal.org [mailto:support-bounces@drupal.org] On Behalf Of Earl Miles Sent: Wednesday, February 21, 2007 2:51 PM To: support@drupal.org Subject: Re: [support] Node Access Table stopped updating
Greg Holsclaw wrote:
All,
Firstly, thank you much for all the support you dole out over the months.
My trouble is that after a while, the node_access table has stopped being updated when new nodes are created. Usually the nid is entered, with realm = all and 'grant_view' = 1. This lets all users who have
the
'access content' permission actually see the node when it is
published.
But without the entries there, anon users can't see anything.
Ordinarily if you have no node access related modules installed, there is a single record for the realm 'all'. Not one per node.
I recented used the Taxonomy Access module, but then inactivated and uninstalled if from my Drupal 5 site. Could it still be causing a problem? Can a server be caching some of the old PHP code somehow.
It wouldn't surprise me if taxonomy access isn't playing nice with the new node access system the way it needs to, and it may not have told Drupal to rebuild the node access table properly when it was disabled.
Visit admin >> content management >> post settings
There is a button to rebuild your node access permissions table. Click that and your node_access database should be restored.
-
Bèr Kessels -
Chris Johnson -
Earl Miles -
Earnie Boyd -
Grandmother Spider -
Greg Holsclaw