webapp cgi debug

Hello,

on an OpenSuse Apache server, there is no way to let a WebApp run.
Calling the cgi from http gives no error, no entry in the apache access logfile.
The cgi runs from command line with no error. In a word: cgi starts, fires the webapp executable, then nothing else happens.

I am not asking what could be the problem, I am asking if you are aware of some way to debug the situation: is there any trick to understand where the connection freezes? I’m on a remote server, so cannot use the remote debugger (because of different IP).

Some facts I’ve already checked out:

  • cgi files are ok on the server (permission)
  • the browser waits forever with a “connecting”, on the server side the webapp is started:

# ps -eaf | grep webtest daemon 9188 4086 0 11:31 ? 00:00:00 /usr/bin/perl -w /usr/local/apache2/cgi-bin/webtest/webtest.cgi daemon 9191 1 0 11:31 ? 00:00:00 /srv/www/cgi-bin/webtest/webtest --port=30411

As you can see I have a link between /srv/www/cgi-bin and /usr/local/apache2/cgi-bin, but I can’t imagine why it shouldn’t work.

Ok, enough for now, hope someone could point me in the right direction.
Thanks,
Roberto

That looks very much like a firewall issue.

Thank you Michel,

yep, my first thought was about firewall. Port 80 is open (obviously), and here comes a doubt:
is the cgi forwarding the http:80 call to the webapp (in my example webtest:30411)? I think it should be something internal from the network pow (i.e. localhost:30411).
From the perl in cgi it is not simple to me to understand this. Anyhow, I tried to open the 30411 port (or whichever port is) with no luck at all. Also, the firewall is not logging any access/block to webapp executable.

You probably won’t get any notices like that. I’m thinking actually that the problem may be with Apache.

You said there was nothing in the Apache access log, but what about the Error log? I also suggest looking at the system log, as you may see something there like a crash or permission error.

Have you tried launching the app itself using ldd to make sure you’re not missing any libraries?

Thanks, Greg.
No error whatsoever. ldd is ok, libraries are ok, If I start the executable alone, it simply exit with no error/output. Btw, the web app is simply an “ok” button.
I will try the same app on another server, and let you know.

Running a CGI from the command line is essentially the same as running a Perl script. It should work.

The web server being configured to allow/run CGI scripts is an entirely different matter.

Thank you Phillip,

I agree. The problem is somewhere in the apache config (I guess), my topic here is how to find it out, not to solve it: as a sysadm, I understand that’s not easy to guess a misconfiguration in a server.
I tested the web app on another two servers…guess? Works ok, both as a standalone or cgi.

About logs: there is no entry in the access or error.log of the apache. That’s weird, I guess I would have the cgi call at least. Nothing, but the webapp is started (as described before). Looks like there is no response from the webapp, the network analyzer in Firefox (have no better tool at the moment) says it has no response from server.

And it is not even a monday…

Well it wouldn’t likely be considered an error on Apache’s side if Apache is not configured to run CGI apps.

It’s impossible for us to diagnose the issue without seeing the Apache config and even then that’s difficult at best. My recommendation is make a backup of your current config and then copy over a working config and isolate that it is in fact the issue. Then you can isolate via a Diff or whatever what the exact settings are that are missing/different.

Apache seems ready for cgi : the Linux executable shows up in the ps in the OP. It has been launched by the cgi, right ?

I find it interesting that the user running perl is named “daemon” and not something like “Apache” or “web” or “www”. I wonder if it’s simply unable to talk to the process because it belongs to another user.

Yes Michel, the executable is launched by the cgi.
Apache can run cgi, other perl script are responding correctly. Also, I replaced the xojo cgi file (webtest.cgi) with a simple perl returning some variables, it works fine. So the problem doesn’t look like an apache permission on the cgi itself.

Good point about the “daemon”. On another server I got:

wwwrun 9502 1 0 10:12 ? 00:00:00 /srv/www/cgi-bin/webtest/webtest --port=25300 wwwrun 9523 19292 0 10:12 ? 00:00:00 /usr/bin/perl -w /srv/www/cgi-bin/webtest/webtest.cgi
On this server the webapp works fine.

I’ll dig a little in this direction.

Just in case someone will find this topic: I found no (evident) solution. Not the apache configuration, nor firewalling.
After a lot of testing (both cgi and standalone), I realized that the problem is on that particular server of mine (the web app works perfectly on other 3 servers). Maybe a system library outdated, maybe a rare network problem. The webapp is reachable, it is contacted by the http requests, then seems sending response to another address (e.g., no answer ever reaches the browser).
I didn’t debug the problem to TCP level, I’ll move to another server to solve this issue.

Than you all for you ideas.
Roberto