Comment 7 for bug 1167337

Hi Steve,
I have tested your scripts some times on one problematic machine.
So far the boots have not failed. But in one test with the old setup the eth0
interface was not started with IP address. So this may be also a reason for
the failing boot. In this case the interface was up but has no IP adress.
after manual issuing dhcpclient, the network was working.
By the way, this problem do I have at the moment also on my home machine
(without nfs/krb5 etc.)
So an other possibility is, that longer delay of dhcpclient cause the problem
for mounting the nfs-fs.
But in one earlier test, I have had a running network, started gssd and no
valid credential for mounting the share. May be this is caused by an other
race condition. I have since that event hanged the default lifetime for /tmp
files from 0 to 2 days, as one idea was the removal of the /tmp/krb_machine
credential during boot after krb5 handshake....

So I will let your scripts installed on this machine and have a look on the
network connection.
Is there a possibility to restart dhcpclient in case of a unsuccessful
inquiry.

On Wednesday 17 April 2013, Steve Langasek wrote:
> On Wed, Apr 17, 2013 at 05:06:18PM -0000, stef wrote:
> > May be a additional flag "-e" has some influence?
> > I use this flag to prevent gssd from blocking the entire system when an
> > users krb-credential has expired to restore the old behavior.
>
> Possible. You could test without that option to see if it affects the boot
> behavior?
>
> Please also test the upstart jobs from 13.04 (linked from my previous
> comment). While these changes don't cause gssd to wait for rpcbind, they
> do fix various other low-probability race conditions, one of which might be
> the root cause of your problem.