On Oct 11, 2013, at 19:01 , Andrew Deason wrote: > On Fri, 11 Oct 2013 17:36:52 +0200 > Stephan Wiesand <[email protected]> wrote: > >>> I don't see anywhere we'd be generating that error code (ENOBUFS), >>> and I can't see how it would show up that way if we got it back from >>> a socket or something. Do you have any idea if the machine is under >>> a lot of load or memory pressure, or if the directory has a lot of >>> entries in it? > > For some reason I never looked at the actual value of this; I thought > ENOBUFS was some low-numbered errno for some reason. But it appears to > be 105, which is VNOSERVICE, which means this is probably due to > idle-dead brokenness. > > Speaking to you in the context of 1.6 maintenance: this isn't really new > (though this specific manifestation might be, I'm not sure). Gerrit 8462 > would help with it, and could possibly go into 1.6.6 if we want to do > something about it. Actually fixing it was discussed in 8464; I just > need to get around to actually implementing it sometime (none of the > submitted patches in there are correct; a different solution is > discussed somewhere in there). > >> To add a data point: >> >> I just encountered this while copying two rather small files for the >> 1.6.5.1 release from here (~ Berlin) to PENN-CENTRAL.SRV.CS.CMU.EDU. > > I assume this was hanging for a little while before erroring out, yes?
Sorry, I really can't tell. When you copy files around a quarter of the globe, there are always delays. And as usual, I fired the command and then went on to something else. I'm fairly sure it didn't hang for more than about a minute though. -- Stephan Wiesand DESY -DV- Platanenenallee 6 15738 Zeuthen, Germany _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
