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@xxxxxxxxx> 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@xxxxxxxxxx> 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
