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