Bug 1088702 - rpcbind not starting with 20180404 Tumbleweed release
rpcbind not starting with 20180404 Tumbleweed release
Status: RESOLVED NORESPONSE
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Basesystem
Current
Other Other
: P5 - None : Major (vote)
: ---
Assigned To: Thomas Blume
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2018-04-09 14:40 UTC by Scott Simpson
Modified: 2018-07-30 15:11 UTC (History)
3 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
Services running right after boot (2.03 KB, text/plain)
2018-04-18 21:30 UTC, Scott Simpson
Details
journalctl info (374.46 KB, text/plain)
2018-04-18 21:30 UTC, Scott Simpson
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Scott Simpson 2018-04-09 14:40:54 UTC
rpcbind didn't start up. I got

Apr 07 11:00:21 madhatter rpcbind[641]: rpcbind: /var/run/rpcbind.lock: No such file or directory
Apr 07 11:00:21 madhatter systemd[1]: rpcbind.service: Main process exited, code=exited, status=1/FAILURE
Apr 07 11:00:21 madhatter systemd[1]: rpcbind.service: Failed with result 'exit-code'.
Apr 07 11:00:21 madhatter systemd[1]: Failed to start RPC Bind.
Apr 07 11:00:21 madhatter systemd[1]: Dependency failed for NIS/YP Clients to NIS Domain Binder.
Apr 07 11:00:21 madhatter systemd[1]: ypbind.service: Job ypbind.service/start failed with result 'dependency'.
Apr 07 11:00:21 madhatter systemd[1]: Dependency failed for NIS/YP Server.
Apr 07 11:00:21 madhatter systemd[1]: ypserv.service: Job ypserv.service/start failed with result 'dependency'.

on boot. rpcbind should take its lock on /run/rpcbind/ directory if that is really needed or find a less racy method of doing so.
Comment 1 Andreas Stieger 2018-04-14 19:48:18 UTC
Thomas could you check this one out please?
Comment 2 Thomas Blume 2018-04-16 10:10:07 UTC
(In reply to Scott Simpson from comment #0)
> 
> on boot. rpcbind should take its lock on /run/rpcbind/ directory if that is
> really needed or find a less racy method of doing so.

I couldn't reproduce this on a stock tumbleweed.
Normally, /var/run should be a symlink to run.
What is the output of:

ls -l /var/run

from your machine?
Comment 3 Scott Simpson 2018-04-16 15:29:13 UTC
ssimpson@madhatter:~$ ls -l /var/run
lrwxrwxrwx 1 root root 4 May 14  2017 /var/run -> /run
ssimpson@madhatter:~$ ls -ld /run
drwxr-xr-x 46 root root 1620 Apr 16 08:05 /run
ssimpson@madhatter:~$ df -h /run
Filesystem      Size  Used Avail Use% Mounted on
tmpfs           3.9G  1.9M  3.9G   1% /run
ssimpson@madhatter:~$
Comment 4 Thomas Blume 2018-04-18 05:41:42 UTC
(In reply to Scott Simpson from comment #3)
> ssimpson@madhatter:~$ ls -l /var/run
> lrwxrwxrwx 1 root root 4 May 14  2017 /var/run -> /run
> ssimpson@madhatter:~$ ls -ld /run
> drwxr-xr-x 46 root root 1620 Apr 16 08:05 /run
> ssimpson@madhatter:~$ df -h /run
> Filesystem      Size  Used Avail Use% Mounted on
> tmpfs           3.9G  1.9M  3.9G   1% /run
> ssimpson@madhatter:~$

I've tried several other setups but still couldn't reproduce the issue.
Does it work if you start rpcbind in the running systemd, e.g:

systemctl start rpcbind

?
If so, it seems that rcpbind has a problem during system startup.
The symlink /var/run is already created in the initrd via:
/usr/lib/dracut/modules.d/30convertfs/convertfs.sh
That shouldn't be a problem.
To find out what happens during startup, please attach the output of:

journalctl -axb
Comment 5 Scott Simpson 2018-04-18 21:30:15 UTC
Created attachment 767653 [details]
Services running right after boot
Comment 6 Scott Simpson 2018-04-18 21:30:41 UTC
Created attachment 767654 [details]
journalctl info
Comment 7 Scott Simpson 2018-04-18 21:34:24 UTC
It is strange. The boot messages say rpcbind failed yet it is running right after boot (see the attached file). ypserv doesn't start up because of a dependency failure. You can see these messages in the "journalctl -axb" output.
Comment 8 Thomas Blume 2018-04-19 07:15:26 UTC
(In reply to Scott Simpson from comment #7)
> It is strange. The boot messages say rpcbind failed yet it is running right
> after boot (see the attached file). ypserv doesn't start up because of a
> dependency failure. You can see these messages in the "journalctl -axb"
> output.

I see the problem.
The boot commandline shows:

rd.lvm.lv=system/usr rd.lvm.lv=system/swap 

which only activates the logical volumes for usr and swap at the initrd stage.

That means /var is only activated later in the boot process and after the first rpcbind startup:

-->
Apr 18 14:11:32 madhatter rpcbind[657]: rpcbind: /var/run/rpcbind.lock: No such file or directory
Apr 18 14:11:32 madhatter systemd[1]: rpcbind.service: Main process exited, code=exited, status=1/FAILURE
Apr 18 14:11:32 madhatter systemd[1]: rpcbind.service: Failed with result 'exit-code'.
Apr 18 14:11:32 madhatter systemd[1]: Failed to start RPC Bind.
-- Subject: Unit rpcbind.service has failed
[...]
Apr 18 14:11:38 madhatter systemd[1]: Mounting /var...
-- Subject: Unit var.mount has begun start-up
--<

Please add:

rd.lvm.lv=system/var

to the boot parameters to make /var available in time.
Comment 9 Thomas Blume 2018-07-30 11:38:43 UTC
No response, closing.
Comment 10 Scott Simpson 2018-07-30 15:10:39 UTC
I had to add the line 

#UUID=7fd430d5-91c8-4680-9b96-6cdfad180579 /var                 btrfs      defaults               0 0
UUID=7fd430d5-91c8-4680-9b96-6cdfad180579 /var                 btrfs      x-initrd.mount              0 0

to get dracut to mount /var from /boot/initrd so /var is mounted before rpcbind starts up. Notice the "initrd.mount" column where it used to say "defaults". If /var was mounted before booting the main kernel I wouldn't have had to do this.
Comment 11 Scott Simpson 2018-07-30 15:11:20 UTC
Sorry, this is from /etc/fstab.