[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [cobalt-users] cgi-wrapper error
- Subject: Re: [cobalt-users] cgi-wrapper error
- From: Alfredo <alfredo@xxxxxxxxxxxxxxx>
- Date: Wed Jan 3 15:19:00 2001
- List-id: Mailing list for users to share thoughts on Cobalt products. <cobalt-users.list.cobalt.com>
The error occurs in /var/log/httpd/error.log.
I know this is probably an easy error, but I'm a total newbie in cgi, so I
don't really know what to do...
The cgi is a simple SSi counter which I included in my html like this:
<!--#exec cgi="/counter.pl" -->
This actually isn't a RAQ question, Marc, and I also don't know what
script you're using but let's at least just go over a couple of
possible issues.
First off, what happens when you make the call like below this:
<!--#exec cgi="counter.pl" -->
Because the way you have the call written, you are treating the
counter program as if it were a directory on the site and that may be
forcing an initial error.
That said, this "cgiwrapper can't be found" error is actually a
generic error and is misleading. It usually means a permissions
problem or some "fatal" problem in the the script (either the perl
definition line, the absense of a "print:content" line or maybe one
of the configuration lines).
Now, IF the script is executing well (upping your little counter
number) but is coughing an error in the logs, this means that one of
the script processes is breaking while the counting and writing
processes are working. If your number is updating, we know the script
is writing to the data file (which you can probably check anyway) so
THAT isn't a problem.
In any case, why don't you open that data file up fully with 777
(just like the directory). Some counter programs need a "world" data
file (for some unfathomable reason) and it's not a particularly
sensitive file so try doing that and see if errors go away.
That said, does the script do anything else at all? Does it email you
when a new person comes aboard? Does it track IPs of visitors?
Anything like that... These are usually the kinds of "secondary
processes" that provoke an error in an otherwise functional script.
If it does, we can look at configurations there.
But do try the call with no "/" in front of it and see what you get.
Alfredo
--
People-Link/Institute for Mass Communications
www.people-link.org
Communications for a Better World...and for the People Who are Building One!
Members, Local 1180, Communications Workers of America, AFL-CIO