Letractively / fuuka

Automatically exported from code.google.com/p/fuuka
Other
0 stars 0 forks source link

Can't run board_dump.pl #40

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
Hey, not sure if you check this or not. I saw that you have the Fuuka code
available for download and decided to set it up for /sp/. I understand why
you stopped archiving /sp/ and I don't blame you but I did really enjoy
easymodo so I was thrilled when I saw I could set it up on my own server.

However once I have the config set up and the sql settled and try to run
board-dump.pl to start archiving I get this and I can't figure it out. Any
help would be greatly greatly appreciated.

bash-3.2$ ./board-dump.pl sp
[0 21 0 0 0 ] 3703812: new
thread failed to start: Undefined subroutine &main::shared_clone called at
./board-dump.pl line 256.
[0 21 0 0 0 ] 3703832: new
thread failed to start: Undefined subroutine &main::shared_clone called at
./board-dump.pl line 256.
[0 21 0 0 0 ] 3703828: new
thread failed to start: Undefined subroutine &main::shared_clone called at
./board-dump.pl line 256.
[0 21 0 0 0 ] 3703855: new
thread failed to start: Undefined subroutine &main::shared_clone called at
./board-dump.pl line 256.
[0 21 0 0 0 ] 3702336: new
thread failed to start: Undefined subroutine &main::shared_clone called at
./board-dump.pl line 256.
[0 21 0 0 0 ] 3703425: new
thread failed to start: Undefined subroutine &main::shared_clone called at
./board-dump.pl line 256.
A thread exited while 10 threads were running.

Original issue reported on code.google.com by kik...@gmail.com on 11 Mar 2010 at 12:40

GoogleCodeExporter commented 8 years ago
What OS/Linux distro are you running? Is your perl compiled with ithreads 
support
(check with perl -V | grep ithread)?

Also, can I get the output of:
perl -Mthreads::shared -e 'print "$threads::shared::VERSION\n"'
?

fuuka requires threads::shared 1.21+.

I am going to guess you're either running perl 5.8.8, which ships with
threads::shared version 0.94 or perl 5.10.0, which ships with 1.14.

You have two options: upgrade your perl (perl 5.8.9 ships with 1.27; 5.0.11 
with 1.29
-- both are recent enough) or keep your old perl version and just upgrade your
threads::shared module (either from CPAN or your OS's packages mechanisms).

Also, if you want SQL dumps + tars with the thumbnails of what I archived from 
/sp/
so far, I can provide that.

Original comment by eksopl on 11 Mar 2010 at 1:17

GoogleCodeExporter commented 8 years ago
You're absolutely right, it's running 0.94. Also useithreads is set to define. 
It's
working perfectly now. If you want to send me the dumps that would be amazing. 
Thanks
for helping so quickly btw.

Original comment by kora...@gmail.com on 11 Mar 2010 at 4:54

GoogleCodeExporter commented 8 years ago
Spoke too soon.

[100 0 5 0 2 ] Couldn't insert posts into database: MySQL server has gone away
[100 0 4 0 2 ] Couldn't insert posts into database: MySQL server has gone away
[100 0 3 0 2 ] Couldn't insert posts into database: MySQL server has gone away
[100 0 2 0 2 ] Couldn't insert posts into database: MySQL server has gone away
[100 0 1 0 2 ] Couldn't insert posts into database: MySQL server has gone away
[100 0 0 0 2 ] Couldn't insert posts into database: MySQL server has gone away
[100 0 0 0 2 ] 3710204: updated
[100 0 0 0 0 ] Couldn't insert posts into database: MySQL server has gone away
[100 0 0 0 0 ] 3710158: front page update
[100 0 0 0 2 ] Couldn't insert posts into database: MySQL server has gone away

Any ideas? There are threads showing on the page but the process keeps spitting 
this out.

Original comment by kik...@gmail.com on 11 Mar 2010 at 4:58

GoogleCodeExporter commented 8 years ago
You restarted the MySQL server with the dumper running. Just restart the board 
dumper.

I'll make dumps available, by the way.

Original comment by eksopl on 11 Mar 2010 at 5:41

GoogleCodeExporter commented 8 years ago
Yeah I thought that as well but every time I run the dumper after about 5 
minutes it
starts spitting that out. Odd but I'll keep trying to figure out the 
disconnect. If
you don't mind, can you send me the config settings you used for /sp/ as well?

Also, I realize this isn't for support and I'm really thankful for the help 
you've
given, but do you have any idea how I can get the reports daemon to work?
Can't exec "wgnuplot": No such file or directory at ./board-reports-demon.pl 
line 154.

I'm assuming this is because it's trying to call wgnuplot when it should call
gnuplot. The server is running CENTOS btw.

Original comment by kik...@gmail.com on 11 Mar 2010 at 6:09

GoogleCodeExporter commented 8 years ago
Do: show variables like 'wait_timeout'; on your mysql prompt. Default is 28800, 
which
is 8 hours. You probably have a ridiculously low value there. If so, just edit 
your
my.cnf file and increase that value.

Also, to enable graphs, edit your board-config.pl file and set the GNUPLOT 
variable
to the path of your gnuplot executable. You need gnuplot 4.2+ with gd support
compiled in.

Original comment by eksopl on 11 Mar 2010 at 6:23

GoogleCodeExporter commented 8 years ago
Holy shit it was set to 20. I have no idea why, maybe something to do with 
caching
or.. something. Everything is running really smoothly now. Except for the fact 
that
the graphs aren't actually being created. The files are created, but they are 
empty.
The daemon isn't spitting out any errors. I was thinking it may just take a 
longer
sample time before it actually generates the graphs. Sorry if it seems like I'm
asking you to handhold me through setting this up. Cause I kind of am. All the 
other
reports are working fine though.

Original comment by kora...@gmail.com on 11 Mar 2010 at 10:10

GoogleCodeExporter commented 8 years ago
Since you're on CentOS 5, you probably have gnuplot 4.1. Check with gnuplot -V.

Original comment by eksopl on 11 Mar 2010 at 10:42

GoogleCodeExporter commented 8 years ago
Ah it's 4.4 but I compiled the damn thing wrong. Graphs now work. Everything 
works in
fact. One last question. Do I set up a cronjob to run these every 5 hours 
(based on
the mysql timeout)? Other than that it's perfect.

Original comment by kora...@gmail.com on 11 Mar 2010 at 11:08

GoogleCodeExporter commented 8 years ago
Umh? No, just leave both the dumper and the report daemon running.

MySQL timeout is the number of hours a connection can stay idling. Obviously 
your
dumper won't stay several hours without sending data to the MySQL server 
(unless you
set extremely low refresh times in the config file), so this isn't an issue.

Original comment by eksopl on 11 Mar 2010 at 11:13

GoogleCodeExporter commented 8 years ago
Sorry. I get it. Screened it and I'm letting it run. Thank you for all your 
help. I'm
really no sysadmin wiz or anything just a guy with a few servers. Would you mind
emailing me the tar/sql when you have a chance? Other than that I'm out of your 
hair.

Original comment by kik...@gmail.com on 11 Mar 2010 at 11:28

GoogleCodeExporter commented 8 years ago
Sure, will do.

You can add me on MSN (this email address) or IM me on AIM (eksopl) if you have 
any
other questions.

Original comment by eksopl on 11 Mar 2010 at 11:42