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

Reply via email to