Bug 1421471 - failure to start: /run/rpcbind/rpcbind.lock: No such file or directory
Summary: failure to start: /run/rpcbind/rpcbind.lock: No such file or directory
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: rpcbind
Version: 25
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Steve Dickson
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-02-12 14:37 UTC by Frank Ch. Eigler
Modified: 2017-09-20 06:24 UTC (History)
8 users (show)

Fixed In Version: rpcbind-0.2.4-5.fc25 rpcbind-0.2.4-6.fc26
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-03-24 18:55:53 UTC


Attachments (Terms of Use)

Description Frank Ch. Eigler 2017-02-12 14:37:21 UTC
Under fedora 25, even with selinux in permissive mode, a straight ypbind configuration fails to start because its prerequisite rpcbind service fails to start:

systemd[1]: Starting RPC Bind...
rpcbind[8297]: rpcbind: /run/rpcbind/rpcbind.lock: No such file or directory
systemd[1]: rpcbind.service: Main process exited, code=exited, status=1/FAILURE
systemd[1]: Failed to start RPC Bind.

There is no more information posted about what went wrong, even if rpcbind is started in debugging mode.

However, this systemd service tweak seems to help:

--- /lib/systemd/system/rpcbind.service 2017-01-28 15:58:58.000000000 -0500
+++ ./rpcbind.service   2017-02-12 09:36:08.424784942 -0500
@@ -7,11 +7,12 @@
 # Make sure we use the IP addresses listed for
 # rpcbind.socket, no matter how this unit is started.
 Wants=rpcbind.socket systemd-tmpfiles-setup.service
-After=rpcbind.socket systemd-tmpfiles-setup.service
+After=rpcbind.socket systemd-tmpfiles-setup.service network.target
 
 [Service]
 Type=notify
 EnvironmentFile=/etc/sysconfig/rpcbind
+ExecStartPre=/bin/mkdir -p /run/rpcbind
 ExecStart=/usr/sbin/rpcbind $RPCBIND_OPTIONS -w -f
 
 [Install]

Comment 1 Steve Dickson 2017-02-13 15:42:51 UTC
(In reply to Frank Ch. Eigler from comment #0)
> However, this systemd service tweak seems to help:
> 
> --- /lib/systemd/system/rpcbind.service 2017-01-28 15:58:58.000000000 -0500
> +++ ./rpcbind.service   2017-02-12 09:36:08.424784942 -0500
> @@ -7,11 +7,12 @@
>  # Make sure we use the IP addresses listed for
>  # rpcbind.socket, no matter how this unit is started.
>  Wants=rpcbind.socket systemd-tmpfiles-setup.service
> -After=rpcbind.socket systemd-tmpfiles-setup.service
> +After=rpcbind.socket systemd-tmpfiles-setup.service network.target
This was never needed before... I wonder what has changed.
>  
>  [Service]
>  Type=notify
>  EnvironmentFile=/etc/sysconfig/rpcbind
> +ExecStartPre=/bin/mkdir -p /run/rpcbind
This should not be needed since this is what systemd-tmpfiles-setup.service should be doing.

>  ExecStart=/usr/sbin/rpcbind $RPCBIND_OPTIONS -w -f
>  
>  [Install]

Comment 2 Frank Ch. Eigler 2017-02-13 15:57:39 UTC
> > -After=rpcbind.socket systemd-tmpfiles-setup.service
> > +After=rpcbind.socket systemd-tmpfiles-setup.service network.target
> This was never needed before... I wonder what has changed.

Not sure it -is- necessary.  With the limited diagnostics of rpcbind, it's hard to know.  (I seem to recall that starting it by hand, some time after a boot, sometimes worked.)

> >  [Service]
> >  Type=notify
> >  EnvironmentFile=/etc/sysconfig/rpcbind
> > +ExecStartPre=/bin/mkdir -p /run/rpcbind
> This should not be needed since this is what systemd-tmpfiles-setup.service
> should be doing.

I don't see an rpcbind related clause in any of the tmpfiles.d directories.

Comment 3 Steve Dickson 2017-02-13 21:59:46 UTC
(In reply to Frank Ch. Eigler from comment #2)
> > > -After=rpcbind.socket systemd-tmpfiles-setup.service
> > > +After=rpcbind.socket systemd-tmpfiles-setup.service network.target
> > This was never needed before... I wonder what has changed.
> 
> Not sure it -is- necessary.  With the limited diagnostics of rpcbind, it's
> hard to know.  (I seem to recall that starting it by hand, some time after a
> boot, sometimes worked.)
Yeah I see this with a number of packages... 


> 
> > >  [Service]
> > >  Type=notify
> > >  EnvironmentFile=/etc/sysconfig/rpcbind
> > > +ExecStartPre=/bin/mkdir -p /run/rpcbind
> > This should not be needed since this is what systemd-tmpfiles-setup.service
> > should be doing.
> 
> I don't see an rpcbind related clause in any of the tmpfiles.d directories.
Moving the lock file has been very painful... probably a mistake :-(
but with rpcbind-0.2.4-4 you are still seeing this problem?

Comment 4 Frank Ch. Eigler 2017-02-14 19:28:40 UTC
Removing my /etc/systemd custom rpcbind.service, using the up-to-date f25 rpcbind 0.2.4-2.fc25.i686, no go:

● rpcbind.service - RPC Bind
   Loaded: loaded (/usr/lib/systemd/system/rpcbind.service; enabled; vendor preset: disabled)
   Active: failed (Result: exit-code) since Tue 2017-02-14 14:24:35 EST; 55s ago
     Docs: man:rpcbind(8)
  Process: 540 ExecStart=/usr/bin/rpcbind $RPCBIND_OPTIONS -w -f (code=exited, status=1/FAILURE)
 Main PID: 540 (code=exited, status=1/FAILURE)

Feb 14 14:24:35 brutus.elastic.org rpcbind[540]: rpcbind: /run/rpcbind/rpcbind.lock: No such file or directory
Feb 14 14:24:35 brutus.elastic.org systemd[1]: rpcbind.service: Main process exited, code=exited, status=1/FAILURE
Feb 14 14:24:35 brutus.elastic.org systemd[1]: Failed to start RPC Bind.
Feb 14 14:24:35 brutus.elastic.org systemd[1]: rpcbind.service: Unit entered failed state.
Feb 14 14:24:35 brutus.elastic.org systemd[1]: rpcbind.service: Failed with result 'exit-code'.

Yet ... after the boot, /run/rpcbind exists:

[root@brutus ~]# ls -al /run/rpcbind
total 0
drwx------.  2 rpc  rpc    40 Feb 14 14:24 .
drwxr-xr-x. 45 root root 1280 Feb 14 14:24 ..

And a # service rpcbind start succeeds.
So I suspect there's some timing problem.  Hm, the new rpcbind.service does not prereq the tmpfiles service.  Is that intentional?

Comment 5 Steve Dickson 2017-02-14 21:07:15 UTC
(In reply to Frank Ch. Eigler from comment #4)

> 
> And a # service rpcbind start succeeds.
> So I suspect there's some timing problem.  Hm, the new rpcbind.service does
> not prereq the tmpfiles service.  Is that intentional?
prereq?? What is that? Its the first I've hear of that... 

So the answer to your question is... no! :-)

Comment 6 Frank Ch. Eigler 2017-02-14 21:28:04 UTC
I meant:

Requires=systemd-tmpfiles-setup.service
After=systemd-tmpfiles-setup.service

Comment 7 Steve Dickson 2017-02-21 13:56:43 UTC
(In reply to Frank Ch. Eigler from comment #6)
> I meant:
> 
> Requires=systemd-tmpfiles-setup.service
> After=systemd-tmpfiles-setup.service

Currently there is 

Wants=rpcbind.socket systemd-tmpfiles-setup.service
After=rpcbind.socket systemd-tmpfiles-setup.service

With Requires I believe rpcbind will be started 
every time systemd-tmpfiles-setup is started??

Comment 8 Frank Ch. Eigler 2017-02-21 15:11:48 UTC
Either Requires | Wants  probably works in this context.
Please by the way also update F24; the same problem appears to exist there.

Comment 9 Georg Sauthoff 2017-03-12 17:07:47 UTC
I can reproduce this issue on a freshly installed Fedora 25 with rpcbind-0.2.4-4.fc25.x86_64:

# systemctl start rpcbind
Mar 12 17:30:45 example.org systemd[1]: Starting RPC Bind...
Mar 12 17:30:45 example.org rpcbind[1783]: rpcbind: /run/rpcbind/rpcbind.lock: No such file or directory
Mar 12 17:30:45 example.org systemd[1]: rpcbind.service: Main process exited, code=exited, status=1/FAILURE
Mar 12 17:30:45 example.org systemd[1]: Failed to start RPC Bind.

I can work around this via:

# systemd-tmpfiles --create /usr/lib/tmpfiles.d/rpcbind.conf
# systemctl start rpcbind
#

cf. https://bugzilla.redhat.com/show_bug.cgi?id=1401561#c68

Comment 10 Fedora Update System 2017-03-21 17:25:17 UTC
rpcbind-0.2.4-5.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2017-66c84b1ba8

Comment 11 Fedora Update System 2017-03-21 17:26:04 UTC
rpcbind-0.2.4-6.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-5c5fcde1a0

Comment 12 Fedora Update System 2017-03-22 15:27:33 UTC
rpcbind-0.2.4-6.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-5c5fcde1a0

Comment 13 Fedora Update System 2017-03-22 20:21:32 UTC
rpcbind-0.2.4-5.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2017-66c84b1ba8

Comment 14 Fedora Update System 2017-03-24 18:55:53 UTC
rpcbind-0.2.4-5.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.

Comment 15 Fedora Update System 2017-04-01 17:23:52 UTC
rpcbind-0.2.4-6.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.

Comment 16 Maël Lavault 2017-04-11 07:24:30 UTC
Issue is still here with rpcbind-0.2.4-5.fc25

Comment 17 Steve Dickson 2017-04-13 14:36:13 UTC
(In reply to Maël Lavault from comment #16)
> Issue is still here with rpcbind-0.2.4-5.fc25

This must be a different problem

Comment 18 Maël Lavault 2017-04-18 09:58:33 UTC
If I go in gnome-logs I can see: 


systemd-tmpfile
Failed to open 'rpcbind.conf': No such file or directory

Looks like the same issue, what do you think ?

Comment 19 Steve Dickson 2017-04-18 14:45:40 UTC
(In reply to Maël Lavault from comment #18)
> If I go in gnome-logs I can see: 
> 
> 
> systemd-tmpfile
> Failed to open 'rpcbind.conf': No such file or directory
> 
> Looks like the same issue, what do you think ?

No. This problem was because the rpcbind.lock file could
not be created because /run/rpcbind was not being
created when rpcbind was not started by systemd.

The problem you are seeing is different. So there 
is no rpcbind.conf under /usr/lib/tmpfiles.d?

Comment 20 Maël Lavault 2017-04-18 15:50:09 UTC
Ah ok, so I do have a rpcbind.conf under /usr/lib/tmpfiles.d and permissions are the same as all other files in this directory.

Comment 21 sixpack13 2017-06-03 22:14:26 UTC
maybe a workaround:

for a homebrewed kernel I set

CONFIG_AF_RXRPC=y
CONFIG_AF_RXRPC_IPV6=y
CONFIG_AF_RXRPC_INJECT_LOSS=y
CONFIG_AF_RXRPC_DEBUG=y

Comment 22 Steve Dickson 2017-06-05 17:11:52 UTC
(In reply to Maël Lavault from comment #20)
> Ah ok, so I do have a rpcbind.conf under /usr/lib/tmpfiles.d and permissions
> are the same as all other files in this directory.

So why can't systemd access that file? selinux??

Comment 23 Maël Lavault 2017-06-07 08:43:41 UTC
No idea... selinux is disabled...

Comment 24 Steve Dickson 2017-06-12 13:55:21 UTC
(In reply to Maël Lavault from comment #23)
> No idea... selinux is disabled...

Can you please post the any error messages you
get when booting?

Also does systemctl restart rpcbind work?

Comment 25 Maël Lavault 2017-06-12 13:59:22 UTC
juin 12 10:20:18 localhost kernel: calling  init_sunrpc+0x0/0x6e [sunrpc] @ 349
juin 12 10:20:18 localhost kernel: RPC: Registered named UNIX socket transport module.
juin 12 10:20:18 localhost kernel: RPC: Registered udp transport module.
juin 12 10:20:18 localhost kernel: RPC: Registered tcp transport module.
juin 12 10:20:18 localhost kernel: RPC: Registered tcp NFSv4.1 backchannel transport module.
juin 12 10:20:18 localhost kernel: initcall init_sunrpc+0x0/0x6e [sunrpc] returned 0 after 142 usecs
juin 12 10:20:18 localhost systemd-tmpfiles[356]: Failed to open 'rpcbind.conf': No such file or directory
juin 12 10:20:18 localhost dracut-pre-udev[336]: rpcbind: /run/rpcbind/rpcbind.lock: No such file or directory
juin 12 10:20:18 localhost rpc.statd[360]: Version 2.1.1 starting
juin 12 10:20:18 localhost rpc.statd[360]: Initializing NSM state
juin 12 10:20:18 localhost rpc.statd[360]: Running as root.  chown /var/lib/nfs/statd to choose different user
juin 12 10:20:18 localhost rpc.statd[360]: Failed to register (statd, 1, udp): svc_reg() err: RPC: Remote system error - Connection refused
juin 12 10:20:18 localhost kernel: usb 1-5: new full-speed USB device number 3 using xhci_hcd
juin 12 10:20:18 localhost rpc.statd[360]: Failed to register (statd, 1, tcp): svc_reg() err: RPC: Remote system error - Connection refused
juin 12 10:20:18 localhost rpc.statd[360]: Failed to register (statd, 1, udp6): svc_reg() err: RPC: Remote system error - Connection refused
juin 12 10:20:18 localhost rpc.statd[360]: Failed to register (statd, 1, tcp6): svc_reg() err: RPC: Remote system error - Connection refused
juin 12 10:20:18 localhost rpc.statd[360]: failed to create RPC listeners, exiting


And yes restart do work perfectly.

Comment 26 piero ds 2017-09-20 06:24:31 UTC
Downloaded fedora 26 x86)64 1 week ago, does not even boot after a fresh install.
Only starts in rescue mode, drops to a shell with 
"dracut pre udev 344 /run/rpcbind/rpcbind.lock: no such file or directory"

sysinfo:

rpm -q rpcbind
rpcbind-0.2.4-8.rc2.fc26.x86_64

rpm -q dracut
dracut-046-2.git20170811.fc26.x86_64

uname -a
4.11.8-300.fc26.x86_64

Since I cannot disable rpcbind (nothing works without it) and rpcbind is latest version, I am totally blocked, I cannot use my computer.

I had to write this report from another computer.
Never before had Fedora failed to boot, much less on a fresh install, not even on hardware problems.

Please somebody provide at least a workaround, it's totally critical.


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