Re: Boot time improvement with systemd and nfs-utils

Hackintosh Five
2021-01-04T18:55:02Z

The issue isn't with the forking type, that's certainly correct (since
it does indeed fork). The problem is that systemd is putting a
dependency between nfs-client (required by multi-user.target) and
rpc-statd-notify (which requires network-online), resulting in gdm
waiting for network-online. The only workaround I was able to make
work was to create a new timer unit which simply launches sm-notify
after 1 second. nfs-client can start the timer unit, which then
*asynchronously* starts sm-notify, meaning that sm-notify gets to keep
its dependency on network-online. Patch with that method will be sent
in a moment (if git send-email decides to work)

On Mon, Jan 4, 2021 at 6:00 PM Chuck Lever <chuck.lever@oracle.com> wrote:
>
> I'm not aware of a similar reason why the notify step would need to
> block the boot process. Maybe Type=forking is wrong, but I thought
> sm-notify was a forking/daemonizing type of utility.
>
>
> > On Jan 4, 2021, at 11:03 AM, Hackintosh Five <hackintoshfive@gmail.com> wrote:
> >
> > I see. Does rpc-statd-notify HAVE to start before nfs-client? If not,
> > perhaps a one-off timer unit with no delay could be made so that the
> > startup of rpc-statd-notify doesn't block the boot process, while
> > still running after network-online?
> >
> > On Mon, Jan 4, 2021 at 1:26 PM Chuck Lever <chuck.lever@oracle.com> wrote:
> >>
> >> The problem is not in sm-notify itself, it's in the C library functions. The system's DNS resolver configuration is set during network startup. When a process first attempts a DNS query, it retrieves the system DNS configuration as it is at that moment, and keeps that configuration until the process exits. If sm-notify starts before the system's DNS resolver is configured, then it simply doesn't work because it can't perform DNS queries correctly.
>
>
> --
> Chuck Lever
>
>
>