Comment 7 for bug 806761

The odd behavior turned out to be a race condition between the nslcd and nslcd-k5start scripts: per the Upstart docs (http://upstart.ubuntu.com/cookbook/#expect), Upstart assumes the job has started after the first PID that is generated in the script, unless an expect stanza is present. So, Upstart believes the nslcd-k5start job has started as soon as the calls to sed/hostname/etc are made and starts the nslcd job, which fails because it can't find the credentials cache it needs.

I can think of three options, none of which look good:

1) Use kinit in a pre-start script for the nslcd-k5start job, and duplicate the K5START_START logic in both the pre-start script and the main script.
2) Re-solve the problem that Upstart's supposed to solve with a signalling system, like letting the nslcd job wait until the nslcd-k5start job had set a flag (or a timeout occurs). Something like a spin lock.
3) Stall the nslcd script for set period of time and hope the nslcd-k5start script doesn't take very long to start.

At the moment, option 3 seems like the best of the bad options: introducing an extra dependency and duplicating control logic seems like a good way to introduce bugs, and implementing a lock system is robust but complicated. A revised debdiff that uses the third option is attached. I'm quite open to arguments in favor of another option, and I'd be delighted to know of a non-hackish solution.