I recently set up a system that needed Passenger's ability to pass on environment variables from the user's shell to their app. To my surprise I found that the variables were not set when my app ran.

At first I suspected that something was wrong with my setup, as I use a rather unorthodox shell setup. So I set about checking every step of the startup process; from which shell I use, to my startup scripts. Everything looked fine, so I assumed the problem must be with Passenger itself.

Little did I know that this would lead me down a long path towards a micro-enlightenment, as well as a Passenger improvement.

Debugging on

While debugging I added logging which tells me which shell Passenger thinks I use and if that shell matches any of the supported shells for loading envvars. I also added a flag to the arguments that are passed to the shell, namely the -x flag. And after compiling and running my setup again, I was presented with a complete trace of what my shell was actually doing on startup.

It turned out that I had a block at the top of my script that conditionally exited the script if bash had been invoked non-interactively; which of course it had been, since Passenger doesn't need the interactive capabilities of the shell. But my eyes simply skipped over it when reviewing my script because it's so normal to be there that I didn't think about what it really means.

This went from a frustrating exercise in guessing what was wrong to being able to see, immediately what was wrong. All because of one extra flag.

Passenger just got a bit better

So what does this mean for Passenger users? Just that it will be much easier to track down issues with environment variables in the next release, version 5.1.3. All you'll have to do is set your log level to 7 and you'll get a nice dump of the setup your shell goes through on startup. If you are interested, the relevant commit in Passenger is 51f0876.