Description of problem: nfsometer -n 3 n36l:/var/crypt/incoming cthon (in an screen, in an ssh session) against a server that does not do v3 Version-Release number of selected component: nfsometer-1.1-2.fc18 Additional info: cmdline: /usr/bin/python /usr/bin/nfsometer -n 3 n36l:/var/crypt/incoming cthon executable: /usr/bin/nfsometer kernel: 3.7.2-204.fc18.x86_64 uid: 1000
Created attachment 686293 [details] File: backtrace
Created attachment 686294 [details] File: core_backtrace
Created attachment 686295 [details] File: environ
It appears to me that is a simple case that the client cannot mount the server do to (probably) a firewall issue. Without NFSometer involved does the following command work? sudo mount -v -t nfs -o vers=3 n36l:/var/crypt/incoming /mnt
(In reply to comment #0) [...] > against a server that does not do v3 (In reply to comment #5) > It appears to me that is a simple case that the client cannot mount the > server do to (probably) a firewall issue. I was kind of expecting NFSometer to fail gracefully instead of triggering ABRT. Maybe that expectation is wrong. (if so simply close this bug) > Without NFSometer involved does > the following command work? > > sudo mount -v -t nfs -o vers=3 n36l:/var/crypt/incoming /mnt Nope. $ sudo mount -v -t nfs -o vers=3 n36l:/var/crypt/incoming /mnt [sudo] password for pcfe: mount.nfs: timeout set for Thu Jan 24 15:12:40 2013 mount.nfs: trying text-based options 'vers=3,addr=192.168.50.250' mount.nfs: prog 100003, trying vers=3, prot=6 mount.nfs: trying 192.168.50.250 prog 100003 vers 3 prot TCP port 2049 mount.nfs: prog 100005, trying vers=3, prot=17 mount.nfs: trying 192.168.50.250 prog 100005 vers 3 prot UDP port 48404 mount.nfs: portmap query retrying: RPC: Unable to receive - No route to host mount.nfs: prog 100005, trying vers=3, prot=6 mount.nfs: trying 192.168.50.250 prog 100005 vers 3 prot TCP port 56914 mount.nfs: portmap query failed: RPC: Remote system error - No route to host mount.nfs: trying text-based options 'vers=3,addr=192.168.50.250' mount.nfs: prog 100003, trying vers=3, prot=6 [... etc ...]
(In reply to comment #6) > (In reply to comment #0) > [...] > > against a server that does not do v3 > > > (In reply to comment #5) > > It appears to me that is a simple case that the client cannot mount the > > server do to (probably) a firewall issue. > > I was kind of expecting NFSometer to fail gracefully instead of triggering > ABRT. Maybe that expectation is wrong. (if so simply close this bug) > > > Without NFSometer involved does > > the following command work? > > > > sudo mount -v -t nfs -o vers=3 n36l:/var/crypt/incoming /mnt > > Nope. > > $ sudo mount -v -t nfs -o vers=3 n36l:/var/crypt/incoming /mnt > [sudo] password for pcfe: > mount.nfs: timeout set for Thu Jan 24 15:12:40 2013 > mount.nfs: trying text-based options 'vers=3,addr=192.168.50.250' > mount.nfs: prog 100003, trying vers=3, prot=6 > mount.nfs: trying 192.168.50.250 prog 100003 vers 3 prot TCP port 2049 > mount.nfs: prog 100005, trying vers=3, prot=17 > mount.nfs: trying 192.168.50.250 prog 100005 vers 3 prot UDP port 48404 > mount.nfs: portmap query retrying: RPC: Unable to receive - No route to host > mount.nfs: prog 100005, trying vers=3, prot=6 > mount.nfs: trying 192.168.50.250 prog 100005 vers 3 prot TCP port 56914 > mount.nfs: portmap query failed: RPC: Remote system error - No route to host > mount.nfs: trying text-based options 'vers=3,addr=192.168.50.250' > mount.nfs: prog 100003, trying vers=3, prot=6 > [... etc ...] Did you ever figure out why your client could not talk to the server? basically why "RPC: Unable to receive - No route to host" is happening?
(In reply to comment #7) > (In reply to comment #6) > > (In reply to comment #0) > > [...] > > > against a server that does not do v3 [...] > Did you ever figure out why your client could not talk to the server? > basically why "RPC: Unable to receive - No route to host" is happening? I do not expect this server to do NFS version 3, it's firewalled off and all my clients here do NFSv4 just fine. The bug is meant to be about nfsometer not failing gracefully in the case of being pointed at a server that does NFSv4 only and triggering abrt.
This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.