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 <heinl...@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. > > -- > Paul Heinlein > heinl...@madboa.com > 45°38' N, 122°6' W_______________________________________________ > PLUG mailing list > PLUG@pdxlinux.org > http://lists.pdxlinux.org/mailman/listinfo/plug > _______________________________________________ PLUG mailing list PLUG@pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
