Re: [PATCH 2/7] clstated: reattempt the pipe open if it fails on ENOENT

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Filesystem Development]     [Linux USB Development]     [Linux Media Development]     [Video for Linux]     [Linux NILFS]     [Linux Audio Users]     [Yosemite Info]     [Linux SCSI]

  Powered by Linux