Stories
Slash Boxes
Comments

Slash Open Source Project

This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login
Loading... please wait.
  • We're troubleshooting a similar problem to what Michael is seeing. I'd really appreciate some suggestions on where to look--we're hurting and need to figure this out.

    We recently upgraded our Slash site to a newer faster box, and in the process upgraded MySQL to the latest. Now we've had several instances of the scheduled tasks grinding to a halt as the result of a process that gets wedged.

    In Michael's mail he listed an nidex.pl task that was running. In our case, we've had both schedule index.pl and article.pl (out of freshenup.pl) get stuck. These should normally take a second or so to process:

    Fri Jan 24 16:55:35 2003 Updating 03/01/24/1339257 Fri Jan 24 16:55:36 2003 article.pl virtual_user=VUser ssi=yes sid='03/01/24/1\ 339257' section='articles' bytes=10577 Also, like Michael, the last thing in our log was the 'Updating yy/mm/dd/article' message from freshenup.pl. Since this process didn't complete, no other scheduled tasks were started. Our slashboxes weren't updated, and the article counts on the front page weren't updating, etc. Basically the same symptoms that Michael's reported.

    We've studied the code extensively and concluded that the freshenup.pl task is sitting at POSIX:waitpid(), waiting for article.pl. No clue as to why article.pl is getting stuck--it mostly makes database calls.

    When I kill the stuck task and rerun it manually (by invoking perl article.pl etc) it always comletes.

    Our operating environment is as follows. We upgraded some packages during our move to a new box and suspect there's some interaction between them, so I'm half expecting a "Slash is known to not work with that version" response.



    RedHat 7.3 base
    Slash 2.2.6
    perl-5.6.1-34.99.6
    mod_perl-1.26-5
    apache-1.3.27-2
    mysql-3.23.54a-3.72
    perl-DBI-1.21-1

    Any suggestions are appreciated, including debugging hints.

    As a secondary problem--not sure this is related--we've had the slash process die with the following sql error twice now. This error we haven't had time to fully investigate yet.

    Tue Feb 4 06:07:00 2003 Send Admin Mail Begin DBD::mysql::st execute failed: Got error 127 from table handler at /usr/lib/perl5/site_perl/5.6.1/i386-linux/Slash/DB /Utility.pm line 260. Error in library:Slash::DB::Static::MySQL:/usr/lib/perl5/si te_perl/5.6.1/i386-linux/Slash/DB/Static/MySQL.pm: 329:SELECT count(*) FROM accesslog WHERE to_days(now()) - to_days(ts)=1 GROUP BY host_addr Which was called by:main:/common/slash/runtime/site/msnews.bostoncu re.org/tasks/adminmail.pl:28:SELECT count(*) FROM accesslog WHERE to_days(now()) - to_days(ts)=1 GROUP BY host_addr Can't call method "rows" on an undefined value at /usr/lib/perl5/site_perl/5.6.1/i386-linux/Slash/DB /Static/MySQL.pm line 331.

    Thanks in advance,

    Brian Del Vecchio
    MSNews: http://msnews.bostoncure.org/
    • by rgoun (3129) on Wednesday February 05 2003, @07:33AM (#5642) Homepage

      I'm running almost exactly the same versions on one of my boxes. Though I don't (currently) have Slash running on it, I didn't have the problem you're seeing when I was running it there. The only difference I see is that I have mysql-3.23.54a-3.73, not mysql-3.23.54a-3.72. I haven't taken the time to see if there's any significant difference between the version built for 7.2. and the one built for 7.3, but I'd look into this.

      Good luck!

      --
      * [wdr1.com] uptime: 00:13:01 up 55 days, 13:18, 9 users, load