Murphy's Law as applied to bugs: it is easier to find bugs in production than in development
Well, that [1] could have gone better.
One bug due to inattention and a difference between development and production, and one “how the XXXX did this ever work in the first place?” bug later, things should be working fine.
I am not going to say “I hope” this time.
The first bug prevented a proper HTTP (HyperText Transport Protocol) status code from being generated, so Apache nicely generated a “500 Interner Server Error” for me. Once I identified what was going on, it was a simple one line fix [2], and an additional call to assert() [3] to help isolate such errors in the future.
Now on to the other error …
I added the concept of a hook [4] to mod_blog [5] a few years ago, and the scripts I have for the various hooks all start with #!/usr/bin/env lua. Only now they weren't running, and the error that was being logged wasn't exactly helpful: entry-pre-hook='./validate.lua' status=127. There is no place in mod_blog nor in the validate.lua script that exits with a status code of 127. But the env program does!
Nice to learn that.
But back to the issue at hand—I've been using these scripts for a few years now, and only now is it failing? I eventually found out that the path Apache is using is rather limited, and it no longer includes the Lua interpreter (which on my server lives in /usr/local/bin). I had to change both scripts to start with #!/usr/local/bin/lua and that fixed the issue to get the previous post up.
Now that I think about it, I think I know why it finally stopped working after a few years—I actually have an instance of Apache running that I didn't start by hand, and the default path at boot time doesn't include /usr/local/bin.
[5] https://github.com/spc476/mod_blog
Source