Bug 963189 - Please do not pull in rpcbind.service from multi-user.target
Please do not pull in rpcbind.service from multi-user.target
Product: Fedora
Classification: Fedora
Component: rpcbind (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Steve Dickson
Fedora Extras Quality Assurance
Depends On:
Blocks: WhyWeBootSoSlow 1036791
  Show dependency treegraph
Reported: 2013-05-15 07:07 EDT by Lennart Poettering
Modified: 2014-09-22 10:22 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1036791 (view as bug list)
Last Closed: 2014-09-22 10:22:05 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Lennart Poettering 2013-05-15 07:07:55 EDT
rpcbind.service is currently pulled in by multi-user.target unconditionally, even though it is socket-activated on-demand via rpcbind.socket, and even though it actually appears to be the ideal case where something can be lazy-loaded on-demand, simply because most people don't use it, but is installed anyway.

lazy-loading it on-demand is transparent to the client, so there really isn't any drawback to socket-activate it.

To make this work, simply drop The line "WantedBy=multi-user.target" from /usr/lib/systemd/system/rpcbind.service. 

(And while you are at it, please drop "After=syslog.target network.target", too. syslog.target is entirely unnecessary these days, all services get syslog support for free anyway. And I don't see why rpcbind should require the network in any way. It just listens on and AF_UNIX which both are available at any time anyway, so there's no need to wait for the network or anything.)

Note You need to log in before you can comment on or make changes to this bug.