in reply to Re: is there a way to (temporarily) switch off mod_perl caching/variable storing?
in thread is there a way to (temporarily) switch off mod_perl caching/variable storing?
Glad they say 'the only stupid question is the one not asked' because otherwise my questions would always win the prize
Of course. Just dont use mod_perl at all
So I set up a script dir via introducing a ScriptAlias... line in my httpd.conf and ran the test scripts there. It looks like my suspicions are correct - it runs every time without complaint under CGI.
So the next question is, what can I do now? Of course I don't want to have to work under CGI. Is there a way I can get mod_perl to flush its buffers? Or some way to get better visibility of what it is actually doing that is causing the problem?
|
---|
Replies are listed 'Best First'. | |
---|---|
Re^3: is there a way to (temporarily) switch off mod_perl caching/variable storing? (contrast compare)
by Anonymous Monk on Jul 11, 2013 at 08:27 UTC | |
So the next question is, what can I do now? compare and contrast Each proc comes with STDIN/STDOUT/STDERR/@ARGV/%ENV/CWD so you dump %ENV/Cwd between the mod_perl and cgi versions, between the successfull and failed ones, and then you check to see whats different Do the same for each function ( open or die ... ; chdir or die ...; ...) I don't know, but that cd /test/repo could fail for some reason ... so verify everything, Git::Wrapper can help ( How to script git with perl and Git::Wrapper | David Golden ) If what you've posted is really the misbehaving code, it might be that you need to sanitize %ENV General notions you should be aware of as well as lists of things to check are found in Coping with Scoping , CGI to mod_perl Porting. mod_perl Coding guidelines , brian's Guide to Solving Any Perl Problem, CGI Help Guide , Troubleshooting Perl CGI scripts , On debugging, verify everything, talk to teddybear ... | [reply] [d/l] |
by tomgracey (Scribe) on Jul 11, 2013 at 12:47 UTC | |
I checked the 'cd' in a separate script - it's definitely not this. Not sure if Git::Wrapper is helpful - I tried originally with this but was getting similar errors which was what drove me to simple system commands. I figured Git::Wrapper was just adding unnecessary complexity (since I don't know how it works) ? I am now running the following:
The environment variables look like this: When it fails under mod_perl
When it succeeds under mod_perl (ie first run after restarting apache)
When it runs in CGI
I couldn't see any noticeable differences there? (but I really dont know what I'm looking for!) In fact I did investigate environment variables earlier but couldn't find any references in the documentation to things that git needed setting (beyond the path to the git binary - let me know if anyone knows more on this?). At that time I compared command line/browser. I discovered 'strace' on my google travels and added this. Not really sure how to analyse the output though! I wont post the full output as it is very long - but when it fails it starts
I dont know if this is significantly different from when it succeeds (first run)
or in CGI:
Below are the last few lines of the strace before it falls over:
When it succeeds on the first run, it appears to execute more commands before arriving at what I guess is the same place, which looks like:
I will continue my investigations but just on the off chance this means something to someone. Many thanks for your help so far! | [reply] [d/l] [select] |
by tomgracey (Scribe) on Jul 12, 2013 at 09:18 UTC | |
Very big hat off to the real wizard on google groups "git for human beings" who solved this conundrum (I wont say who as I haven't asked for permission - but you can find the thread under the title 'frustrations trying to control git through apache'). Here is an extract of his diagnosis: So we see that: 1) The Git code is poorly documented, and there is no coding control to ensure that the code is internally documented. 2) The test "if (fd > 0) return fd;" is incorrect. It should be "(fd >= 0)". 3) The error is triggered if fd 0 (standard-input) is closed when Git starts and Git needs to put a file into the object store. In your situation, that is determined by the particular Git operation and the details of how Git is invoked by Apache. From this, we can construct a simple test case that demonstrates the bug:
So there you have it. Nothing to do with environment variables, and mod_perl was a red herring The fix? Add </dev/null to any (bash) line being executed that involves a write (or otherwise ensure standard input is not closed when git tries to open the file). Unfortunately this appears to mean *any* git module (Git::Wrapper, Git::Repository... ) is unusable for me (and I would be surprised if not for other people aswell?), and I must use home grown code... Btw the bug has been reported And now it works! I am so happy =D | [reply] [d/l] [select] |