Bug 2098193

Actually, maybe it's the After= line, which seems odd.  I've removed the Wants entries and that did seem to help.

Sorry, I was failing to properly remove the Wants= (can't use autofs.service.d/override.conf to remove Wants=).

(In reply to Orion Poplawski from comment #0)
> Description of problem:
> 
> We use NFSv4 mounts only and so do not need rpc-statd or rpcbind, but
> starting autofs starts them presumably due to:
> 
> Wants=network-online.target rpc-statd.service rpcbind.service
> 
> Version-Release number of selected component (if applicable):
> autofs-5.1.4-82.el8.x86_64

What problems does this cause?

There were some odd problems that lead to adding some of those entries,
I'll need to check why.

And be aware I'm going to be out of action for a while so there will
be a delay in me getting back to you, sorry.

Ian

(In reply to Orion Poplawski from comment #0)
> Description of problem:
> 
> We use NFSv4 mounts only and so do not need rpc-statd or rpcbind, but
> starting autofs starts them presumably due to:

There were some problems recently.

You know that, if you want to use NFSv4 without autofs trying to
contact rbcbind, you need to disable fallback to other NFS protocol
versions in your map entries.

That needs to be done by using the fstype option and setting it
to nfs4.

(In reply to Ian Kent from comment #4)
> (In reply to Orion Poplawski from comment #0)
> > Description of problem:
> > 
> > We use NFSv4 mounts only and so do not need rpc-statd or rpcbind, but
> > starting autofs starts them presumably due to:
> 
> There were some problems recently.
> 
> You know that, if you want to use NFSv4 without autofs trying to
> contact rbcbind, you need to disable fallback to other NFS protocol
> versions in your map entries.
> 
> That needs to be done by using the fstype option and setting it
> to nfs4.

Did you give this some thought?
If specifying the option "fstype=nfs4" doesn't work properly then I'll
need to fix it. 

I'm concerned about breaking other things that have been fixed by just
removing those dependencies.

Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days