[PLUG] Can anyone recommend intligent way to debug not executing CGI scripts on Apache2?

Tomas K tomas.kuchta.lists at gmail.com
Thu Jan 10 08:54:54 UTC 2019


Just in case, someone still think about this topic.
For the lack of other ideas - I resolved the issue by tearing my config
file templates apart and putting them back together from the working
deployed parts. Diffing the old (broken config) and new working one
produces identity, so do access logs. The only difference I can observe
is that in one Apache instance spawns process and executes the .cgi -
returning generated response, while in the broken instance returns .cgi
as text.
I resolved this independently of posting my question - I was hoping to
learn some way of observing/querying what configuration Apache actually
applies internally. That would have allowed me to compare differences
from Apache's point of view, not mine, of the config files.
It would have made a great difference - the next time I have the
same/similar problem. It is akin of knowing how to competently fish
rather than just randomly poking into the water with a spear -
thankfully Apache is not as smart as a fish looking at me from the
water.
Anyway - .cgi execution is one of those areas without log coverage.
Tomas
On Mon, 2019-01-07 at 13:52 -0800, Tomas Kuchta wrote:
> The problem is 99.99999% in the Apache config - the same application
> runs on one server not the other. No matter which way I synchronize
> the code, it executes in one place, not the other.
> The only difference are Apache config files, produced mostly with
> Jinja templates and search and replace with a few config lines added
> related to host aliases to flip things to production.
> 
> Often, the whole thing ends up working after a few days of tearing it
> apart and putting it back together. I have a feeling that it may be
> something like not printable characters or a white space typo, ....
> In any case it is not producing any load errors. Diffing config files
> produces identity with the exception of the host name and intentional
> differences.
> 
> I tried dos2unix, etc too. ... All I can come up with is to take it
> apart randomly and put it back together until I get lucky and it all
> works. No, errors, no messages, no hints. Web is full of similar
> (Apache does not execute my code) issues with no suggestion how to go
> after it other than eye balling the configs.
> 
> On Mon, Jan 7, 2019, 1:31 PM Paul Heinlein <heinlein at madboa.com
> wrote:
> > On Mon, 7 Jan 2019, Tomas Kuchta wrote:
> > 
> > 
> > 
> > > Yes, the file serving part works, and is observable in the logs.
> > There is
> > 
> > > good visibility on client side with curl or browsers. When Apache
> > executes
> > 
> > > it, I get the output html/json/.... When it doesn't work, I get
> > to download
> > 
> > > the code.
> > 
> > >
> > 
> > > I usually build couple of identical machines and synchronize
> > their
> > 
> > > config/content. Still, when one machine in the pair is stubbornly
> > refusing
> > 
> > > to run some stuff, it takes a lot of diffing, renaming,
> > rebuilding, ...
> > 
> > >
> > 
> > > What makes Apache to choose to execute some files and not the
> > others, is
> > 
> > > the $M question.
> > 
> > 
> > 
> > There are a few possible answers.
> > 
> > 
> > 
> > First, the non-executing scripts may live in a directory not 
> > 
> > identified by a ScriptAlias directive or in a directory that
> > doesn't 
> > 
> > have "SetHandler cgi-script" and "Options +ExecCGI" configured.
> > 
> > 
> > 
> > Second, if the CGI script is handled by an interpreter
> > (/usr/bin/perl, 
> > 
> > for example, or /usr/bin/python) the #! line may be incorrect or
> > the 
> > 
> > file may not be marked as executable in the filesystem.
> > 
> > 
> > 
> > Third, the CGI script fails to set the Content-Type header of the 
> > 
> > return text correctly. Use "curl -I <<your failing url>>" to see.
> > In 
> > 
> > cases where it's failing, you're probably getting "text/plain";
> > but 
> > 
> > where it's successful you're seeing "application/json".
> > 
> > 
> > 
> > Those are the most likely cases I can imagine.
> > 
> > 
> > 
> > 


More information about the PLUG mailing list