For several weeks, maybe several months, most of my Rawhide installations generate an error trying to mount noauto nfs items in fstab:
Job for rpc-statd.service failed. See 'systemctl status rpc-statd.service' and 'journalctl -xn' for details.
Output from those: [start]rpc-statd.service - NFS status monitor for NFSv2/3 locking. Loaded: loaded (/usr/lib/systemd/system/rpc-statd.service; enabled) Active: failed (Result: exit-code) since Thu 2014-05-29 00:41:00 EDT; 3min 12s ago Process: 691 ExecStart=/usr/sbin/rpc.statd --no-notify $STATDARGS (code=exited, status=1/FAILURE)
May 29 00:40:00 g5eas systemd[1]: Starting NFS status monitor for NFSv2/3 locking.... May 29 00:40:00 g5eas rpc.statd[692]: Version 1.3.0 starting May 29 00:40:00 g5eas rpc.statd[692]: Flags: TI-RPC May 29 00:41:00 g5eas rpc.statd[692]: failed to create RPC listeners, exiting May 29 00:41:00 g5eas systemd[1]: rpc-statd.service: control process exited, code=exited status=1 May 29 00:41:00 g5eas systemd[1]: Failed to start NFS status monitor for NFSv2/3 locking.. May 29 00:41:00 g5eas systemd[1]: Unit rpc-statd.service entered failed state. -- Logs begin at Sat 2014-03-22 18:49:34 EDT, end at Thu 2014-05-29 00:41:00 EDT. -- May 29 00:40:00 g5eas rpcbind[693]: cannot create socket for tcp6 May 29 00:40:00 g5eas systemd[1]: Started RPC bind service. -- Subject: Unit rpcbind.service has finished start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit rpcbind.service has finished starting up. -- -- The start-up result is done. May 29 00:40:07 g5eas systemd[1]: Starting Stop Read-Ahead Data Collection... -- Subject: Unit systemd-readahead-done.service has begun with start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit systemd-readahead-done.service has begun starting up. May 29 00:40:07 g5eas systemd[1]: Started Stop Read-Ahead Data Collection. -- Subject: Unit systemd-readahead-done.service has finished start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit systemd-readahead-done.service has finished starting up. -- -- The start-up result is done. May 29 00:41:00 g5eas rpc.statd[692]: failed to create RPC listeners, exiting May 29 00:41:00 g5eas systemd[1]: rpc-statd.service: control process exited, code=exited status=1 May 29 00:41:00 g5eas systemd[1]: Failed to start NFS status monitor for NFSv2/3 locking.. -- Subject: Unit rpc-statd.service has failed -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit rpc-statd.service has failed. -- -- The result is failed. May 29 00:41:00 g5eas systemd[1]: Unit rpc-statd.service entered failed state. May 29 00:41:00 g5eas rpc.statd[709]: Version 1.3.0 starting May 29 00:41:00 g5eas rpc.statd[709]: Flags: TI-RPC [end]
I see no similar problem in Factory or Cauldron using identical fstab entries and mount syntax. What needs to be done to eliminate this delay?
On Thu, 2014-05-29 at 00:48 -0400, Felix Miata wrote:
May 29 00:40:00 g5eas rpcbind[693]: cannot create socket for tcp6
I don't know what's causing it, but this to me looks like the most likely candidate for the underlying problem.
On 2014-05-29 09:08 (GMT-0700) Adam Williamson composed:
On Thu, 2014-05-29 at 00:48 -0400, Felix Miata wrote:
May 29 00:40:00 g5eas rpcbind[693]: cannot create socket for tcp6
I don't know what's causing it, but this to me looks like the most likely candidate for the underlying problem.
It shouldn't be. I know the indirect reason must be ipv6.disable=1 on cmdline, but have no idea more directly why something that never needed ipv6 before now stalls because it's not available, and only in Rawhide but not Factory or Cauldron.
On Thu, 2014-05-29 at 12:53 -0400, Felix Miata wrote:
On 2014-05-29 09:08 (GMT-0700) Adam Williamson composed:
On Thu, 2014-05-29 at 00:48 -0400, Felix Miata wrote:
May 29 00:40:00 g5eas rpcbind[693]: cannot create socket for tcp6
I don't know what's causing it, but this to me looks like the most likely candidate for the underlying problem.
It shouldn't be. I know the indirect reason must be ipv6.disable=1 on cmdline, but have no idea more directly why something that never needed ipv6 before now stalls because it's not available, and only in Rawhide but not Factory or Cauldron.
Can you check boots from before you started seeing the problem, and see if that error message is present or not? Can you identify precisely when the problem started happening (should be possible using journalctl's neat filtering/searching options)? Thanks!
On 2014-05-29 11:29 (GMT-0700) Adam Williamson composed:
On Thu, 2014-05-29 at 12:53 -0400, Felix Miata wrote:
On 2014-05-29 09:08 (GMT-0700) Adam Williamson composed:
On Thu, 2014-05-29 at 00:48 -0400, Felix Miata wrote:
May 29 00:40:00 g5eas rpcbind[693]: cannot create socket for tcp6
I don't know what's causing it, but this to me looks like the most likely candidate for the underlying problem.
It shouldn't be. I know the indirect reason must be ipv6.disable=1 on cmdline, but have no idea more directly why something that never needed ipv6 before now stalls because it's not available, and only in Rawhide but not Factory or Cauldron.
Can you check boots from before you started seeing the problem, and see if that error message is present or not? Can you identify precisely when the problem started happening (should be possible using journalctl's neat filtering/searching options)? Thanks!
x32 host gx280 last upgraded 10 May has no delay with nfs-utils-1.3.0-1.2, kernel 3.15rc5
x64 host gx62b last upgraded 26 May has delay with nfs-utils-1.3.0-1.3, kernel 3.15rc6
Would any more precision be available via journalctl?
On non-afflicted x32 host gx27b last updated 08 May, first journalctl hit on rpcbind cannot create socket for [udp6,tcp6] dates to 02 December.
Afflicted host gx62b's first such hit is 27 Mar, which is directly followed by rpcbind no such files /var/lib/rpcbind/[rpcbind.xdr,portmap.xdr]. Also then were 5 successive firewalld ipv6 errors for not exist or no permissions for filter, raw, security, mangle, nat, and again rpcbind no xdrs, the rpc.statd failed to create RPC listeners. Most of these repeated on subsequent boots through 26 May. The exception was failed RPC listeners, which skipped from 21 April to 29 May.
I don't know that I have the right kind of bait or fishin pole for this kind of fishin. :-p
On 2014-05-29 13:20 (GMT-0700) Felix Miata composed:
On 2014-05-29 11:29 (GMT-0700) Adam Williamson composed:
On Thu, 2014-05-29 at 12:53 -0400, Felix Miata wrote:
On 2014-05-29 09:08 (GMT-0700) Adam Williamson composed:
On Thu, 2014-05-29 at 00:48 -0400, Felix Miata wrote:
May 29 00:40:00 g5eas rpcbind[693]: cannot create socket for tcp6
I don't know what's causing it, but this to me looks like the most likely candidate for the underlying problem.
It shouldn't be. I know the indirect reason must be ipv6.disable=1 on cmdline, but have no idea more directly why something that never needed ipv6 before now stalls because it's not available, and only in Rawhide but not Factory or Cauldron.
Can you check boots from before you started seeing the problem, and see if that error message is present or not? Can you identify precisely when the problem started happening (should be possible using journalctl's neat filtering/searching options)? Thanks!
x32 host gx280 last upgraded 10 May has no delay with nfs-utils-1.3.0-1.2, kernel 3.15rc5
x64 host gx62b last upgraded 26 May has delay with nfs-utils-1.3.0-1.3, kernel 3.15rc6
Would any more precision be available via journalctl?
On non-afflicted x32 host gx27b last updated 08 May, first journalctl hit on rpcbind cannot create socket for [udp6,tcp6] dates to 02 December.
Afflicted host gx62b's first such hit is 27 Mar, which is directly followed by rpcbind no such files /var/lib/rpcbind/[rpcbind.xdr,portmap.xdr]. Also then were 5 successive firewalld ipv6 errors for not exist or no permissions for filter, raw, security, mangle, nat, and again rpcbind no xdrs, the rpc.statd failed to create RPC listeners. Most of these repeated on subsequent boots through 26 May. The exception was failed RPC listeners, which skipped from 21 April to 29 May.
I don't know that I have the right kind of bait or fishin pole for this kind of fishin. :-p
Well over a month later this is still very highly annoying:
# systemctl status rpc-statd rpc-statd.service - NFS status monitor for NFSv2/3 locking. Loaded: loaded (/usr/lib/systemd/system/rpc-statd.service; enabled) Active: failed (Result: exit-code) since Thu 2014-07-10 16:56:32 EDT; 1min 53s ago Process: 643 ExecStart=/usr/sbin/rpc.statd --no-notify $STATDARGS (code=exited, status=1/FAILURE)
# journaltcl -xn
â rpc-statd.service - NFS status monitor for NFSv2/3 locking. Loaded: loaded (/usr/lib/systemd/system/rpc-statd.service; enabled) Active: failed (Result: exit-code) since Thu 2014-07-10 16:56:32 EDT; 6min ago Process: 643 ExecStart=/usr/sbin/rpc.statd --no-notify $STATDARGS (code=exited, status=1/FAILURE)
Jul 10 16:55:32 gx62b systemd[1]: Starting NFS status monitor for NFSv2/3 locking.... Jul 10 16:55:32 gx62b rpc.statd[644]: Version 1.3.0 starting Jul 10 16:55:32 gx62b rpc.statd[644]: Flags: TI-RPC Jul 10 16:56:32 gx62b rpc.statd[644]: failed to create RPC listeners, exiting Jul 10 16:56:32 gx62b systemd[1]: rpc-statd.service: control process exited, code=exited status=1 Jul 10 16:56:32 gx62b systemd[1]: Failed to start NFS status monitor for NFSv2/3 locking.. Jul 10 16:56:32 gx62b systemd[1]: Unit rpc-statd.service entered failed state. -- Logs begin at Wed 2014-03-26 23:52:34 EDT, end at Thu 2014-07-10 17:01:01 EDT. -- Jul 10 16:56:32 gx62b rpc.statd[660]: Version 1.3.0 starting Jul 10 16:56:32 gx62b rpc.statd[660]: Flags: TI-RPC Jul 10 17:01:01 gx62b systemd[1]: Starting Session 2 of user root. -- Subject: Unit session-2.scope has begun with start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit session-2.scope has begun starting up. Jul 10 17:01:01 gx62b systemd[1]: Started Session 2 of user root. -- Subject: Unit session-2.scope has finished start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit session-2.scope has finished starting up. -- -- The start-up result is done. Jul 10 17:01:01 gx62b CROND[750]: (root) CMD (run-parts /etc/cron.hourly) Jul 10 17:01:01 gx62b run-parts[753]: (/etc/cron.hourly) starting 0anacron Jul 10 17:01:01 gx62b anacron[759]: Anacron started on 2014-07-10 Jul 10 17:01:01 gx62b run-parts[761]: (/etc/cron.hourly) finished 0anacron Jul 10 17:01:01 gx62b anacron[759]: Will run job `cron.daily' in 18 min. Jul 10 17:01:01 gx62b anacron[759]: Jobs will be executed sequentially
On 2014-07-10 17:04 (GMT-0400) Felix Miata composed:
On 2014-05-29 13:20 (GMT-0700) Felix Miata composed:
On 2014-05-29 11:29 (GMT-0700) Adam Williamson composed:
On Thu, 2014-05-29 at 12:53 -0400, Felix Miata wrote:
On 2014-05-29 09:08 (GMT-0700) Adam Williamson composed:
On Thu, 2014-05-29 at 00:48 -0400, Felix Miata wrote:
May 29 00:40:00 g5eas rpcbind[693]: cannot create socket for tcp6
I don't know what's causing it, but this to me looks like the most likely candidate for the underlying problem.
It shouldn't be. I know the indirect reason must be ipv6.disable=1 on cmdline, but have no idea more directly why something that never needed ipv6 before now stalls because it's not available, and only in Rawhide but not Factory or Cauldron.
Can you check boots from before you started seeing the problem, and see if that error message is present or not? Can you identify precisely when the problem started happening (should be possible using journalctl's neat filtering/searching options)? Thanks!
x32 host gx280 last upgraded 10 May has no delay with nfs-utils-1.3.0-1.2, kernel 3.15rc5
x64 host gx62b last upgraded 26 May has delay with nfs-utils-1.3.0-1.3, kernel 3.15rc6
Would any more precision be available via journalctl?
On non-afflicted x32 host gx27b last updated 08 May, first journalctl hit on rpcbind cannot create socket for [udp6,tcp6] dates to 02 December.
Afflicted host gx62b's first such hit is 27 Mar, which is directly followed by rpcbind no such files /var/lib/rpcbind/[rpcbind.xdr,portmap.xdr]. Also then were 5 successive firewalld ipv6 errors for not exist or no permissions for filter, raw, security, mangle, nat, and again rpcbind no xdrs, the rpc.statd failed to create RPC listeners. Most of these repeated on subsequent boots through 26 May. The exception was failed RPC listeners, which skipped from 21 April to 29 May.
I don't know that I have the right kind of bait or fishin pole for this kind of fishin. :-p
Well over a month later this is still very highly annoying:
# systemctl status rpc-statd rpc-statd.service - NFS status monitor for NFSv2/3 locking. Loaded: loaded (/usr/lib/systemd/system/rpc-statd.service; enabled) Active: failed (Result: exit-code) since Thu 2014-07-10 16:56:32 EDT; 1min 53s ago Process: 643 ExecStart=/usr/sbin/rpc.statd --no-notify $STATDARGS (code=exited, status=1/FAILURE)
# journaltcl -xn
â rpc-statd.service - NFS status monitor for NFSv2/3 locking. Loaded: loaded (/usr/lib/systemd/system/rpc-statd.service; enabled) Active: failed (Result: exit-code) since Thu 2014-07-10 16:56:32 EDT; 6min ago Process: 643 ExecStart=/usr/sbin/rpc.statd --no-notify $STATDARGS (code=exited, status=1/FAILURE)
Jul 10 16:55:32 gx62b systemd[1]: Starting NFS status monitor for NFSv2/3 locking.... Jul 10 16:55:32 gx62b rpc.statd[644]: Version 1.3.0 starting Jul 10 16:55:32 gx62b rpc.statd[644]: Flags: TI-RPC Jul 10 16:56:32 gx62b rpc.statd[644]: failed to create RPC listeners, exiting Jul 10 16:56:32 gx62b systemd[1]: rpc-statd.service: control process exited, code=exited status=1 Jul 10 16:56:32 gx62b systemd[1]: Failed to start NFS status monitor for NFSv2/3 locking.. Jul 10 16:56:32 gx62b systemd[1]: Unit rpc-statd.service entered failed state. -- Logs begin at Wed 2014-03-26 23:52:34 EDT, end at Thu 2014-07-10 17:01:01 EDT. -- Jul 10 16:56:32 gx62b rpc.statd[660]: Version 1.3.0 starting Jul 10 16:56:32 gx62b rpc.statd[660]: Flags: TI-RPC Jul 10 17:01:01 gx62b systemd[1]: Starting Session 2 of user root. -- Subject: Unit session-2.scope has begun with start-up -- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- Unit session-2.scope has begun starting up. Jul 10 17:01:01 gx62b systemd[1]: Started Session 2 of user root. -- Subject: Unit session-2.scope has finished start-up -- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- Unit session-2.scope has finished starting up.
-- The start-up result is done. Jul 10 17:01:01 gx62b CROND[750]: (root) CMD (run-parts /etc/cron.hourly) Jul 10 17:01:01 gx62b run-parts[753]: (/etc/cron.hourly) starting 0anacron Jul 10 17:01:01 gx62b anacron[759]: Anacron started on 2014-07-10 Jul 10 17:01:01 gx62b run-parts[761]: (/etc/cron.hourly) finished 0anacron Jul 10 17:01:01 gx62b anacron[759]: Will run job `cron.daily' in 18 min. Jul 10 17:01:01 gx62b anacron[759]: Jobs will be executed sequentially
Ping? Still happening in f21 and Rawhide, but not Cauldron or Factory. :(
On 2014-07-28 13:07 (GMT-0400) Felix Miata composed:
Ping? Still happening in f21 and Rawhide, but not Cauldron or Factory. :(
Workaround in https://bugzilla.redhat.com/show_bug.cgi?id=1048661 is working on one installation so far out of 2 tried: Rawhide on host g5eas is OK, but not F21 on same host. It's hard to understand, because what to disable (#systemctl disable nfs-secure.service) doesn't show enabled in the first place, only static.
On Mon, 2014-07-28 at 13:07 -0400, Felix Miata wrote:
Ping? Still happening in f21 and Rawhide, but not Cauldron or Factory. :(
Sorry, I'm not seeing anything like it with my NFS mounts. You'd probably best file a bug.
Adam Williamson composed on 2014-07-29 10:13 (UTC-0700):
On Mon, 2014-07-28 at 13:07 -0400, Felix Miata wrote:
Ping? Still happening in f21 and Rawhide, but not Cauldron or Factory. :(
Sorry, I'm not seeing anything like it with my NFS mounts.
Are all yours done manually rather than on boot, via alias that does four mount points, as are mine?
You'd probably best file a bug.
Maybe figure out first if one already exists, and what would go in it? I think this could be one or the other or both of these two: https://bugzilla.redhat.com/show_bug.cgi?id=1046015 https://bugzilla.redhat.com/show_bug.cgi?id=1090617
I haven't been able to notice anything in common among the installations that do, or among the installations that don't, or figure out what to look at. Clearly from systemd-analyze blame the delay is in rpc-statd.service, which on host gx260 is currently delaying almost 2 minutes.
# journalctl -xn -- Logs begin at Wed 2014-03-19 01:26:56 EDT, end at Mon 2014-10-13 21:04:47 EDT. -- Oct 13 21:03:46 gx260 systemd[1]: Starting NFS status monitor for NFSv2/3 locking.... -- Subject: Unit rpc-statd.service has begun with start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit rpc-statd.service has begun starting up. Oct 13 21:03:47 gx260 rpc.statd[676]: Version 1.3.0 starting Oct 13 21:03:47 gx260 rpc.statd[676]: Flags: TI-RPC Oct 13 21:03:47 gx260 systemd[1]: Starting RPC bind service... -- Subject: Unit rpcbind.service has begun with start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit rpcbind.service has begun starting up. Oct 13 21:03:47 gx260 rpcbind[677]: cannot create socket for udp6 Oct 13 21:03:47 gx260 rpcbind[677]: cannot create socket for tcp6 Oct 13 21:03:47 gx260 systemd[1]: Started RPC bind service. -- Subject: Unit rpcbind.service has finished start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit rpcbind.service has finished starting up. -- -- The start-up result is done. Oct 13 21:03:47 gx260 rpcbind[682]: Cannot open '/var/lib/rpcbind/rpcbind.xdr' file for reading, errno 2 (No such file or directory) Oct 13 21:03:47 gx260 rpcbind[682]: Cannot open '/var/lib/rpcbind/portmap.xdr' file for reading, errno 2 (No such file or directory) Oct 13 21:04:47 gx260 systemd[1]: Started NFS status monitor for NFSv2/3 locking.. -- Subject: Unit rpc-statd.service has finished start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit rpc-statd.service has finished starting up. -- -- The start-up result is done.
# systemctl list-unit-files | grep rpc var-lib-nfs-rpc_pipefs.mount static rpc-gssd.service static rpc-statd-notify.service static rpc-statd.service enabled rpc-svcgssd.service static rpcbind.service static rpcbind.socket enabled rpcbind.target static
Cmdline includes ipv6.disable=1 and net.ifnames=0, but removing them produces extra error messages from mount.nfs, and thus delays longer. I tried removing NetworkManager*, but that didn't help either.
Basing a bug on this host (gx260) may be an undesirable thing to do, 32 bit, and old (P4 2.4GHz single core, no HT), and X locks up the machine (new since last updates, in both my i845G systems, both F21 and F22, though not openSUSE's or Mageia's X).
On Mon, 2014-10-13 at 22:05 -0400, Felix Miata wrote:
Adam Williamson composed on 2014-07-29 10:13 (UTC-0700):
On Mon, 2014-07-28 at 13:07 -0400, Felix Miata wrote:
Ping? Still happening in f21 and Rawhide, but not Cauldron or Factory. :(
Sorry, I'm not seeing anything like it with my NFS mounts.
Are all yours done manually rather than on boot, via alias that does four mount points, as are mine?
No, I use systemd auto-mounting.
ircproxy:/ /share/irclogs nfs noauto,user,comment=systemd.automount 0 0
You'd probably best file a bug.
Maybe figure out first if one already exists, and what would go in it?
Well, I'd start out by describing the problem and attaching the journal and the fstab lines and the enable/disable state of the relevant services.
Adam Williamson composed on 2014-10-20 17:28 (UTC-0700):
On Mon, 2014-10-13 at 22:05 -0400, Felix Miata wrote:
Adam Williamson composed on 2014-07-29 10:13 (UTC-0700):
On Mon, 2014-07-28 at 13:07 -0400, Felix Miata wrote:
Ping? Still happening in f21 and Rawhide, but not Cauldron or Factory. :(
Sorry, I'm not seeing anything like it with my NFS mounts.
Are all yours done manually rather than on boot, via alias that does four mount points, as are mine?
No, I use systemd auto-mounting.
ircproxy:/ /share/irclogs nfs noauto,user,comment=systemd.automount 0 0
You'd probably best file a bug.
Maybe figure out first if one already exists, and what would go in it?
Well, I'd start out by describing the problem and attaching the journal and the fstab lines and the enable/disable state of the relevant services.
I may have narrowed down the problem to this:
13 working installations: rpcbind.service enabled
14 broken installations: rpcbind.service static
All those working do not have NetworkManager installed. Half those not working have NetworkManager installed.
On a broken one (host g5eas 32 bit F21, which was and is broken, had NetworkManager installed before I removed it minutes ago, and remains broken) I get the following: systemctl status rpcbind on first login: * rpcbind.service - RPC bind service Loaded: loaded (/usr/lib/systemd/system/rpcbind.service; static) Active: inactive (dead) systemctl status rpcbind after ifup eth0: * rpcbind.service - RPC bind service Loaded: loaded (/usr/lib/systemd/system/rpcbind.service; static) Active: inactive (dead) systemctl status rpcbind after nfs mount attempts: * rpcbind.service - RPC bind service Loaded: loaded (/usr/lib/systemd/system/rpcbind.service; static) Active: active (running) since Tue 2014-10-21 00:52:11 EDT; 1min 39s ago Process: 795 ExecStart=/sbin/rpcbind -w ${RPCBIND_ARGS} (code=exited, status=0/SUCCESS) Main PID: 800 (rpcbind) CGroup: /system.slice/rpcbind.service --800 /sbin/rpcbind -w
Oct 21 00:52:11 g5eas rpcbind[795]: cannot create socket for udp6 Oct 21 00:52:11 g5eas rpcbind[795]: cannot create socket for tcp6 Oct 21 00:52:11 g5eas systemd[1]: Started RPC bind service.
journalctl -xn after above: -- Logs begin at Sat 2014-03-22 16:16:21 EDT, end at Tue 2014-10-21 00:53:11 EDT. -- Oct 21 00:52:43 g5eas systemd[1]: Started Session 2 of user root. -- Subject: Unit session-2.scope has finished start-up -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit session-2.scope has finished starting up. -- -- The start-up result is done. Oct 21 00:52:43 g5eas login[479]: pam_unix(login:session): session opened for user root by LOGIN(uid=0) Oct 21 00:52:43 g5eas login[479]: ROOT LOGIN ON tty2 Oct 21 00:53:11 g5eas rpc.statd[794]: failed to create RPC listeners, exiting Oct 21 00:53:11 g5eas systemd[1]: rpc-statd.service: control process exited, code=exited status=1 Oct 21 00:53:11 g5eas systemd[1]: Failed to start NFS status monitor for NFSv2/3 locking.. -- Subject: Unit rpc-statd.service has failed -- Defined-By: systemd -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel -- -- Unit rpc-statd.service has failed. -- -- The result is failed. Oct 21 00:53:11 g5eas systemd[1]: Unit rpc-statd.service entered failed state. Oct 21 00:53:11 g5eas systemd[1]: rpc-statd.service failed. Oct 21 00:53:11 g5eas rpc.statd[850]: Version 1.3.0 starting Oct 21 00:53:11 g5eas rpc.statd[850]: Flags: TI-RPC
Before filing any bug I'd like to make more progress to get an idea if there actually is any bug, but am not sure where to look in order to make more progress. Systemctl enable rpcbind does not make a change from static to enabled. There is no man page for rpcbind.service. Man rpcbind doesn't look helpful. Man systemctl is a zoo. I've no recollection how networking ever got to work on the installations that do not have NetworkManager, though I suppose that could be fallout from always doing HTTP installations in the first place. System-config-network didn't provide any improvement.
More detail in data/logs collected since Saturday: http://fm.no-ip.com/Tmp/Linux/F/NFS/
Still think I should file a bug already? Any suggestions how to proceed further (first?)?
Felix Miata composed on 2014-10-21 01:23 (UTC-0400):
I may have narrowed down the problem to this:
13 working installations: rpcbind.service enabled
14 broken installations: rpcbind.service static
Turns out finding the solution was stymied by bad 'man systemctl' (216-10.fc22), which says
"enable NAME...
Enable one or more unit files or unit file instances, as specified on the command line...."
That's invalid WRT rpcbind. In order to enable rpcbind I found the following necessary:
systemctl add-wants multi-user.target rpcbind
The question remains how and why 13 of 26 (I miscounted in prior thread post) installations were set to static instead of enabled in the first place.