21.02.2014 01:31, J. Bruce Fields пишет:
On Wed, Feb 19, 2014 at 06:57:46PM +0400, Stanislav Kinsbursky wrote:
19.02.2014 18:50, J. Bruce Fields пишет:
On Wed, Feb 19, 2014 at 02:26:33PM +0400, Stanislav Kinsbursky wrote:
18.02.2014 19:44, J. Bruce Fields пишет:
On Tue, Feb 18, 2014 at 07:19:31PM +0400, Stanislav Kinsbursky wrote:
18.02.2014 02:19, J. Bruce Fields пишет:
On Sat, Feb 15, 2014 at 09:51:20AM +0800, Weng Meiling wrote:
Hi Bruce,
The upstream has merged your git tree for-3.14, but there is no this patch?
Do you forget this patch?
Apologies, I'm not sure what happened.
Looking back at it.... The patch causes all my pynfs reboot recovery
tests to fail. They're just doing a "systemctl restart
nfs-server.service", and "systemctl status nfs-server.service" shows in
part
ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS $RPCNFSDCOUNT (code=exited, status=1/FAILURE)
So the patch is causing rpc.nfsd to fail? No network namespaces should
be involved.
I haven't investigated any further.
Hi Bruce,
Are you sure, that exactly this patch broke your pynfs tests?
BTW, systemd manipulates namespaces. Maybe the patch revealed some pynfs internal bugs?
What do you think?
It's really just "systemctl restart nfs-server.service" that the patch
breaks, pynfs isn't involved much.
The patch I'm actually using follows, but I believe the only difference
is in the printk message?
Yep, looks true.
That's strange: "systemctl restart nfs-server.service" works for me on Fedora 18 with kernel, based on your repo.
OK, I'll take a closer look and let you know what I find.
Thank you, Bruce!
rpc.nfsd's attempt to bind port 2049 the second time is failing with
EADDRINUSE.
svc_alien_sock isn't failing, so the only different here is that we're
running sockfd_lookup....
Does that take a reference on the fd or the sock that needs to be put?
Yes, you right. I missed it, sorry.
Thank you. Will resend.
--b.
--
Best regards,
Stanislav Kinsbursky
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
