#532 Issue closed: rear git201501071534 "rear recover" on Fedora 21: hangs at rpc.statd

Labels: support / question

jsmeix opened issue at 2015-01-20 11:27:

I am testing rear git201501071534 version on Fedora 21:

I boot the rear recovery system which works but see

In the the recovery system I run

rear -d -D recover

which hangs with the last message

Using log file: /var/log/rear/rear-f42.log

RESCUE f42:~ # tail /var/log/rear/rear-f42.log 
++ ((  0 != 0  ))
++ max_portmap_checks=5
++ rpcinfo -p localhost
++ has_binary rpc.statd
++ for bin in '$@'
++ type rpc.statd
++ return 0
++ grep -q status
++ rpcinfo -p localhost
++ rpc.statd
RESCUE f42:~ #

Somehow rpc.statd does not work.

I aborted "rear -d -D recover" (simply [Ctrl]+[C]).

The following dirty hack seems to "fix" it for me:

ln -sf /bin/true /bin/rpc.statd

Afterwards I re-started "rear -d -D recover"
which successfully recovers the system.

jsmeix commented at 2015-01-20 11:30:

RESCUE f42:~ # grep -v '^#' /etc/rear/local.conf
RESCUE f42:~ #

gdha commented at 2015-01-30 12:43:

@jsmeix In my test environment I have no problems with rpc.statd daemon:

In top output it is not showing (systemd and systemd-journal are consuming a lot - issue #531).
Perhaps, the NFS-server is type NFSv4? Could be related to a certain version? Just guessing.

gdha commented at 2015-06-26 14:30:

@jsmeix can this one being closed or do you still have some comments to share?

jsmeix commented at 2015-06-29 06:49:

I cannot remember whether or not I verified that it works for me with the released rear 1.17.0 on Fedora 21.
I think when it works for you, you can close it.
Furthermore I assume if it would not work there would have been same reports from other Fedora 21 users.

[Export of Github issue for rear/rear.]