FS#41433 - [rpcbind] statically enabling the service is crazy

Attached to Project: Arch Linux
Opened by Mantas Mikulėnas (grawity) - Friday, 01 August 2014, 17:36 GMT
Last edited by Tobias Powalowski (tpowa) - Tuesday, 13 January 2015, 18:27 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Tobias Powalowski (tpowa)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 12
Private No

Details

The current package's (0.2.1-5) package() function has the following:

ln -sf ../rpcbind.socket $pkgdir/usr/lib/systemd/system/sockets.target.wants/rpcbind.socket
ln -sf ../rpcbind.service $pkgdir/usr/lib/systemd/system/multi-user.target.wants/rpcbind.service

which permanently enables the service to be started on boot for everyone who has installed it, unless the service is masked. This is Just Wrong™, because it wastes time starting a service which I only need like once a week, and ignores that NFS services have (or should have) proper dependencies on rpcbind.socket and that admins can do `systemctl enable` themselves anyway.

These two symlinks should not be part of a package like this.
This task depends upon

Closed by  Tobias Powalowski (tpowa)
Tuesday, 13 January 2015, 18:27 GMT
Reason for closing:  Fixed
Additional comments about closing:  0.2.2-1
Comment by Tobias Powalowski (tpowa) - Saturday, 02 August 2014, 04:56 GMT
Then remove the package if you don't need it or mask it as you said.
Comment by Dave Reisner (falconindy) - Saturday, 02 August 2014, 13:54 GMT
I don't think it's unreasonable to ask the user to enable these services manually if they're wanted. This is how we treat most services in Arch.
Comment by Tobias Powalowski (tpowa) - Saturday, 02 August 2014, 18:06 GMT
nfs without rpcbind is unusable.
Comment by Dave Reisner (falconindy) - Saturday, 02 August 2014, 18:28 GMT
Then we should express that dependency (rather than avoiding the question) by adding Requires=rpcbind.socket/After=rpcbind.socket (in [Unit]) to services that rely on rpcbind being available.
Comment by Tobias Powalowski (tpowa) - Sunday, 03 August 2014, 05:35 GMT
That way we cannot use upstream service files, cause they explicitly state they will not add rpcbind dependency.
Comment by Swift Geek (swiftgeek) - Thursday, 18 September 2014, 05:13 GMT
But that would be just non-conflicting addition to existing service file(s)… no discarding upstream, but sed
Also this is ridiculous and discards idea of socket units anyway -.-
Comment by Patrick Donnelly (batrick) - Thursday, 25 September 2014, 17:45 GMT
> nfs without rpcbind is unusable.

This is why we have nfs-client.target. Why hasn't this been fixed yet?
Comment by Renato F (renatofdds) - Friday, 17 October 2014, 00:20 GMT
IMHO the rpcbind.service should definitely be enable-based. Installing the package doesn't mean i want it running all the time, if i wanted to i would use "enable".
The solution is just removing $pkgdir/usr/lib/systemd/system/multi-user.target.wants/rpcbind.service. rpcbind.socket could stay, as it serves its purpose.
Comment by Timothée Ravier (Siosm) - Friday, 24 October 2014, 12:43 GMT
According to me the only services that should be install time enabled are the one that must be enabled for a system to boot. That's it, nothing more. Everything else is the administrator's duty.
Comment by Piotr Jurkiewicz (piotrjurkiewicz) - Saturday, 25 October 2014, 23:41 GMT
I registered an account here in order to report exactly the same bug. But I see that it is already reported :)

Installation of package does not imply that a user wants it to being automatically started on every boot. Especially in cases when socket activation mechanism can be utilised.
Comment by Piotr Jurkiewicz (piotrjurkiewicz) - Sunday, 26 October 2014, 02:25 GMT
Furthermore, starting with kernel 3.14, rpcbind is no longer required to run in-kernel NFS server.

(assuming that server is configured to use only NFSv4 and higher)

http://lxr.free-electrons.com/source/net/sunrpc/svc.c?v=3.14#L966

You can find more information about that change in this thread:

http://www.spinics.net/lists/linux-nfs/msg41053.html
Comment by David Parrish (dmp1ce) - Monday, 27 October 2014, 17:30 GMT
I only turn on NFS when I need it for development with Vagrant. I was surprised to see that rpcbind.service was running on a fresh reboot. This is the only package installed on my system that opens a port on install. Now I need to figure out how to mask the rpcbind.service, but at least I know why.

EDIT: For anyone wondering masking is pretty easy: systemctl mask rpcbind.service
Comment by Timothée Ravier (Siosm) - Wednesday, 12 November 2014, 13:55 GMT
The Wiki for NFS users properly states that one should enable and start rpcbind: https://wiki.archlinux.org/index.php/NFS#Client & https://wiki.archlinux.org/index.php/NFS#Starting_the_server.

What's holding this fix? (which is reverting parts of https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/rpcbind&id=62ae5b08aa0dfacf7039278d22dab6558a7b8b6f).
Comment by Patrick Donnelly (batrick) - Wednesday, 12 November 2014, 14:59 GMT
As long as the bug is assigned to someone, Arch developers believe it is fixed. [Just take a look at the number of bugs assigned to the assignee.] I fear no one will fix this bug because they just don't give a fuck.
Comment by Tobias Powalowski (tpowa) - Wednesday, 12 November 2014, 15:02 GMT
At the moment I'm not sure if I will revert this. The number of bugs assigned to me is no indicator of activity most of them are upstream kernel bugs.
Comment by czk (czk) - Monday, 22 December 2014, 20:41 GMT
Re "Then remove the package if you don't need it" - I can't uninstall rpcbind, because nfs-utils requires it.

But I don't need rpcbind on my system, because I'm using NFS 4.1 mounts solely. I only need the (u)mount.nfs4, provided by nfs-utils. See  FS#43180 .

How about decoupling the 2 packages?
Comment by Yuval Adam (yuvadm) - Thursday, 25 December 2014, 01:54 GMT
Same here. Seeing rpcbind actively listening on ports despite systemctl disable'ing it is a huge surprise for a security-aware sysadmin.

This is a large enough problem for me that I'll simply uninstall rpcbind until the next time I need NFS, but this screams to be fixed for users who are rely on NFS more than I do.

Loading...