On Wed, 14 Dec 2011 10:29:49 -0500 Steve Dickson <SteveD@xxxxxxxxxx> wrote: > > > On 12/14/2011 10:19 AM, Jeff Layton wrote: > > On Wed, 14 Dec 2011 10:09:04 -0500 > > Steve Dickson <SteveD@xxxxxxxxxx> wrote: > > > >> > >> > >> On 12/14/2011 08:57 AM, Jeff Layton wrote: > >>> Generally, we want this daemon started before nfsd starts. Deal with the > >>> situation where the pipe hasn't shown up yet. > >> This can be done with your systemd start up script. Plus I'm not sure its > >> a good idea to steal cpu cycles waiting for an event that may never happen... > >> > > > > Presumably you just wouldn't start the daemon if you have no intent to > > use it. > > > > It does sleep 1s between each check, so the time is fairly minimal, > > but I'm definitely open to doing this differently. What may be > > reasonable is adding code to the daemon to check and see if the > > v4recoverydir is present. If it is, then just exit. Otherwise, wait for > > the pipe to show up. > Why just let the systemd scrips worry about the order of when to start > things up... To be honest, that is one thing systemd does do fairly well. > Because not everyone uses systemd, and we have to deal with the "legacy" case too for the transition phase. It's generally preferable not to start up nfsd until everything it needs is up. If we do what you suggest, then we're basically mandating that this daemon can't start until nfsd is up and running. Could you give some details on how you think this ought to work? -- Jeff Layton <jlayton@xxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
