Forum

lx-office on Hiawatha

fallingdutch

26 May 2009, 12:39

Hello all esp. Hugo,

first of all thanks for the great work.

I have a problem with running lx-office http://www.lx-office.org (a german split-off of sql-ledger) on
Hiawatha:

I do get the login page and shows up as wanted, but when going to the admin page I get an CGI Timeout (even with a setting of 180) :

Tue 26 May 2009 12:15:12 +0200|127.0.0.1|/var/www/lx-office-erp/admin.pl|CGI timeout

it does work on Apache so I wonder what it might be ... can I somehow get more detailed informations?
could it be a header bug?

thanks in advance,
falling

Hugo Leisink

26 May 2009, 16:31

If you set TimeForCGI to 180, does it than also take 180 seconds before Hiawatha kills the CGI program and logs the "CGI timeout" message? Or already after a few seconds?

fallingdutch

26 May 2009, 19:41

it does take the 180 seconds until it returns the error ...

Hugo Leisink

26 May 2009, 22:09

Well, in that case the problem must be in your CGI program. How is the processor load during those 180 seconds?

I advice you to print debug information to a logfile throughout admin.pl in order to pinpoint the exact line of code that is causing admin.pl to wait forever. (if a certain debug line is not printed, that line of code wasn't reached)

fallingdutch

26 May 2009, 22:16

thanks Hugo,

I just wonder that it does work on apache and does stop running and print me a nice admin page

(same machine, same files on hd ... once hiawatha once apache)

any Ideas are welcome ... while waiting I will start debugging

Hugo Leisink

26 May 2009, 23:01

Start by looking at the processor load during the request. Hiawatha has forked and started admin.pl. So, somewhere in your process list, a admin.pl as a child of Hiawatha must be present. What is the processor load of that process?

If it's very high, admin.pl is looping on some code. Look for for-loops in the code. If the load is zero, admin.pl is waiting on something. Most likely on the return of a system call. My guess is that that system call has something to do with reading the HTTP request, like reading from stdin.

My way of debugging woud be: locate the start of the script and insert a write-some-text-to-logfile statement. Reload the browser and see if the logfile has the 'text'. If it has, move the log-statement a few lines down in the code. Repeat that step until a browser-refresh doesn't add the text to the logfile. You've come to a point the script execution doesn't reach. If can tell me where that point is, I'll take a look in the code for you to see what's going wrong.

fallingdutch

27 May 2009, 20:30

the processor load was close to zero and I hunted down the line to the following:

read(STDIN, $_, $ENV{CONTENT_LENGTH});

which does not return.

$ENV{CONTENT_LENGTH} is 38

if you need some more informations tell me and I will be glad to give them to you.

thanks for your help, Hugo

falling
groetjes uit duitsland

fallingdutch

27 May 2009, 20:35

just tried the following:

read(STDIN, $_, 1);

and it didn't return either

fallingdutch

27 May 2009, 21:10

did check the $ENV{REQUEST_METHOD} and it is POST

Hugo Leisink

27 May 2009, 21:45

I tried downloading lx-office-erp, but the zip file contains a lot of zero-sized files. admin.pl is also empty..... Can you share admin.pl (and the rest of the code) with me?

fallingdutch

27 May 2009, 21:57

those files are links under linux

admin.pl is a symbolic link to login.pl

then /bin/mozilla/admin.pl is included, which includes SL/Form.pm
and in new() of Form.pm the read is performed

if you still need some code please let me know and I will past it on some bin

groetjes

Hugo Leisink

27 May 2009, 22:41

I've downloaded the package and taken a look at the source...... now I remember why I hate Perl so much. This is nasty ugly code!!

I unzipped the zipfile and pointed my browser to it. All I get is

Wed 27 May 2009 20:39:36 +0200|10.4.0.3|/var/www/test/login.pl|Can't locate Template.pm in @INC (@INC contains: modules/override /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl . modules/fallback) at SL/Form.pm line 58.|BEGIN failed--compilation aborted at SL/Form.pm line 58.|Compilation failed in require at bin/mozilla/login.pl line 33.|BEGIN failed--compilation aborted at bin/mozilla/login.pl line 33.|Compilation failed in require at /var/www/test/login.pl line 89.
Wed 27 May 2009 20:39:36 +0200|10.4.0.3|/var/www/test/login.pl|no output

How do I get this ugly monster running? I don't know Perl very well, so you have to help me out on this one

fallingdutch

27 May 2009, 23:16

neither do I know perl very well ;-)

you need a lot of perl packages ...

two of them are libtemplate-perl and libhtml-template-perl (for debian)

fallingdutch

27 May 2009, 23:44

btw: the debug function you recommend:

sub log {
    open(FILE,"> debug.out") or die("unable to open debug.out\n");
    print FILE "$_[0]\n";
    close(FILE);
}

#calles like this:
log("this is an ugly code");

fallingdutch

27 May 2009, 23:45

sub log {
   # needs to be ">>" not ">" so each line is attached and not just the last line is in the file
    open(FILE,">> debug.out") or die("unable to open debug.out\n");
    print FILE "$_[0]\n";
    close(FILE);
}

#calles like this:
log("this is an ugly code");

Hugo Leisink

28 May 2009, 00:15

Next error I need some help with:

install_driver(Pg) failed: Can't locate DBD/Pg.pm in @INC (@INC contains: modules/override /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl . modules/fallback) at (eval 25) line 3.|Perhaps the DBD::Pg perl module hasn't been fully installed,|or perhaps the capitalisation of 'Pg' isn't right.|Available drivers: AnyData, CSV, DBM, ExampleP, File, Proxy, Sponge, mysql.| at SL/Auth.pm line 144

fallingdutch

28 May 2009, 00:21

you need the pg driver
libdbi-perl and libdbd-pg-perl

Hugo Leisink

28 May 2009, 00:41

I've found the bug: when you submit a password, admin.pl tries to read from stdin twice. It's done in admin.pl on line 54 and in SL/Form.pm (included via bin/mozilla/admin.pl) on line 234. If you disable the read() in SL/Form.pm, it works. I was able to login with 'admin' as the password.

So, it's not a Hiawatha bug, but one in lx-office-erp.

fallingdutch

28 May 2009, 00:55

thank you very much, Hugo.

I will post it as a bug on lx-office

fallingdutch

29 May 2009, 10:16

Hello Hugo,

I did post it as a bug on lx-office and their Idea was that forked perl apps behave not the same way on hiawatha and apache ...

I will dig into it.

Hugo Leisink

29 May 2009, 12:04

I saw your forum post on their website. I believe that there are two things that caused this problem: they designed their website using Apache instead of using the web standards. Second: their design is bad. Reading the request should be done in a centrilized way. One piece of code that reads the request and makes it available to the rest of the website code. That's not what they did. Every piece of software should have a modular and structured design. This is what the lx-office code lacks.

fallingdutch

29 May 2009, 13:10

thank you very much for your help Hugo

I guess I will have to stick to apache until I found something else or they changed their code, which is very unlikely

This topic has been closed.

Back