On Tue, Mar 03, 2015 at 04:37:24PM -0500, Steve Dickson wrote: > > > On 03/03/2015 02:18 PM, Zbigniew Jędrzejewski-Szmek wrote: > > On Tue, Mar 03, 2015 at 10:06:57PM +0300, Andrei Borzenkov wrote: > > Indeed. From the man page: > > -m retry-time > > Specifies the length of time, in minutes, to continue retry‐ > > ing notifications to unresponsive hosts. If this option is > > not specified, sm-notify attempts to send notifications for > > 15 minutes. Specifying a value of 0 causes sm-notify to > > continue sending notifications to unresponsive peers until > > it is manually killed. > > > > Notifications are retried if sending fails, the remote does > > not respond, the remote's NSM service is not registered, or > > if there is a DNS failure which prevents the remote's > > mon_name from being resolved to an address. > > > > So rpc-statd-notify.service should be fine with being started before > > the network is up at all. > Right... that's the point... we want the service to fork and keep trying > in the background.... ...so like Andrei wrote, the dependency on network.target can be removed (I wasn't sure if it was clear what I meant). Zbyszek -- 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
