You can achieve such a workaround, but it's prone to races and unreliable. Better to fix cron and stop it from caching which user exists or not.
My lucid /etc/init/cron.conf for NIS currently looks as given below, and tested on some old-fashioned Pentium 4 HT computer that suffered heavily, with two major changes: A - I've added a pre-start that queries ypwhich up to 30 times to see whether ypbind has started and bound to the server yet, sleeping 1 s after failure. Since ypwhich itself employs timeouts, the actual wait time is longer. B - I've gotten rid of the "expect fork" and use cron's "don't fork mode"; this is an unrelated cleanup and not needed for this particular fix, and the -L2 also bumps up the cron log level. -------------------------------------------------------------------------- # cron - regular background program processing daemon # # cron is a standard UNIX program that runs user-specified programs at # periodic scheduled times description "regular background program processing daemon" start on runlevel [2345] stop on runlevel [!2345] # ma 2011-06-07 hack alert: defer start until ypwhich # returns success, so that NIS can bind to the domain # see https://bugs.launchpad.net/ubuntu/+source/cron/+bug/27520 pre-start script count=30 until ypwhich ; do count=$(( $count - 1 )) if [ $count = 0 ] ; then break ; fi sleep 1 done end script respawn exec cron -L2 -f --------------------------------------------------------------------- -- Matthias Andree -- You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. https://bugs.launchpad.net/bugs/27520 Title: cron daemon caches user-non-existent lookup results, causing "ORPHAN" message and skipping jobs for all LDAP/NIS-defined users -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
