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. ** Patch added: "Revised Upstart scripts" https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/806761/+attachment/3220650/+files/nslcd-upstart.debdiff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/806761 Title: Feature Request: Upstart scripts for nslcd To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nss-pam-ldapd/+bug/806761/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
