| Message ID | 1425407803-5278-1-git-send-email-steved@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
? Tue, 3 Mar 2015 13:36:43 -0500 Steve Dickson <steved@redhat.com> ?????: > Its been reported that having the rpc-statd-notify service > depend on network.target instead network-online.target > decrease boot times as much as 10 seconds on some > installs > If it does not need network when strting, it should not depend on network at all. This will probably decrease boot time even more. If it does need network, it should depend on network-online, this is correct. > Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1183293 > > Signed-off-by: Steve Dickson <steved@redhat.com> > Reported-by: Eric Work <work.eric@gmail.com> > --- > systemd/rpc-statd-notify.service | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/systemd/rpc-statd-notify.service b/systemd/rpc-statd-notify.service > index a655445..b608a14 100644 > --- a/systemd/rpc-statd-notify.service > +++ b/systemd/rpc-statd-notify.service > @@ -1,6 +1,6 @@ > [Unit] > Description=Notify NFS peers of a restart > -Requires=network-online.target > +Requires=network.target > After=network.target nss-lookup.target > > # if we run an nfs server, it needs to be running before we -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Mar 03, 2015 at 10:06:57PM +0300, Andrei Borzenkov wrote: > ? Tue, 3 Mar 2015 13:36:43 -0500 > Steve Dickson <steved@redhat.com> ?????: > > > Its been reported that having the rpc-statd-notify service > > depend on network.target instead network-online.target > > decrease boot times as much as 10 seconds on some > > installs > > > > If it does not need network when strting, it should not depend on > network at all. This will probably decrease boot time even more. > > If it does need network, it should depend on network-online, this is > correct. 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. Zbyszek > > > Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1183293 > > > > Signed-off-by: Steve Dickson <steved@redhat.com> > > Reported-by: Eric Work <work.eric@gmail.com> > > --- > > systemd/rpc-statd-notify.service | 2 +- > > 1 files changed, 1 insertions(+), 1 deletions(-) > > > > diff --git a/systemd/rpc-statd-notify.service b/systemd/rpc-statd-notify.service > > index a655445..b608a14 100644 > > --- a/systemd/rpc-statd-notify.service > > +++ b/systemd/rpc-statd-notify.service > > @@ -1,6 +1,6 @@ > > [Unit] > > Description=Notify NFS peers of a restart > > -Requires=network-online.target > > +Requires=network.target > > After=network.target nss-lookup.target > > > > # if we run an nfs server, it needs to be running before we > > _______________________________________________ > systemd-devel mailing list > systemd-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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.... Thanks for the cycles! steved. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 03/03/2015 05:51 PM, Zbigniew J?drzejewski-Szmek wrote: > 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). I did miss the fact you guys were saying because of the 15min retry network.target is not needed... But, in reality, a network is needed/wanted so leaving it in will document that fact w/out causing any delay. steved. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 03/03/2015 01:36 PM, Steve Dickson wrote: > Its been reported that having the rpc-statd-notify service > depend on network.target instead network-online.target > decrease boot times as much as 10 seconds on some > installs > > Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1183293 > > Signed-off-by: Steve Dickson <steved@redhat.com> > Reported-by: Eric Work <work.eric@gmail.com> Committed... steved. > --- > systemd/rpc-statd-notify.service | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/systemd/rpc-statd-notify.service b/systemd/rpc-statd-notify.service > index a655445..b608a14 100644 > --- a/systemd/rpc-statd-notify.service > +++ b/systemd/rpc-statd-notify.service > @@ -1,6 +1,6 @@ > [Unit] > Description=Notify NFS peers of a restart > -Requires=network-online.target > +Requires=network.target > After=network.target nss-lookup.target > > # if we run an nfs server, it needs to be running before we > -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/systemd/rpc-statd-notify.service b/systemd/rpc-statd-notify.service index a655445..b608a14 100644 --- a/systemd/rpc-statd-notify.service +++ b/systemd/rpc-statd-notify.service @@ -1,6 +1,6 @@ [Unit] Description=Notify NFS peers of a restart -Requires=network-online.target +Requires=network.target After=network.target nss-lookup.target # if we run an nfs server, it needs to be running before we
Its been reported that having the rpc-statd-notify service depend on network.target instead network-online.target decrease boot times as much as 10 seconds on some installs Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1183293 Signed-off-by: Steve Dickson <steved@redhat.com> Reported-by: Eric Work <work.eric@gmail.com> --- systemd/rpc-statd-notify.service | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)