perfSONAR User Q&A and Other Discussion

[Jon Clausen <>]

On 2017-08-07 11:03:35 (+0000), Garnizov, Ivan (RRZE) wrote:
> Hello Jon,

Hi

> Your point for the error message is good:
> ""no route to host" *is* pretty specific, and does suggest a routing issue."
> 
> The problem with this is, that the message is labeled as it is by the 
> kernel. I guess you will agree it will not be a good idea to substitute the 
> kernel messages on our side.

Indeed - as Mark wrote earlier - and I do agree. It was just not clear to me
that the messages originated in the kernel.

> IMHO the only improvement pS Dev could consider is to state the source of 
> the message. Thus it would be easier to differentiate between events from 
> kernel, external application and the service itself.

This might improve the situation, although I'm not actually sure it would
have made "the big difference" to me. Or rather, I'm not sure the
significance of the 'source' would have been clear to me, without the
context Mark provided in his answer.

Still, more info is probably better

br
/jon

> 
> Regards,
> Ivan Garnizov
> 
> GEANT SA1T2: pS deployments GN Operations
> GEANT SA2T3: pS development team
> GEANT SA3T5: eduPERT team
> 
> 
> 
> -----Original Message-----
> From: 
> 
>  
> [mailto:]
>  On Behalf Of Jon Clausen
> Sent: Freitag, 4. August 2017 15:33
> To: Mark Feit
> Cc: 
> 
> Subject: Re: [perfsonar-user] powstream, misleading log entries
> 
> On 2017-08-04 12:52:46 (+0000), Mark Feit wrote:
> > Jon Clausen writes:
> > 
> 
> >     Now, I *think* this classifies as a bug, because the logged info is 
> > actively
> >     misleading. But it's going to be a while before I'd be able to 
> > identify
> >     which component to report the bug against.
> > 
> > Connections rejected for administrative reasons get lumped in with the 
> > “no route to host” error returned by the kernel.  All that comes back is 
> > a number that gets mapped to that string, and there aren’t separate 
> > errors for anything more specific than that. 
> 
> right
> 
> > I agree that the message is a bit misleading in this situation, but it 
> > does fit in a “no way to get there” sort of way even if it’s not the 
> > routing.  If you’d tried connecting to fi-csc-pstp01-mi1.nordu.net:861 
> > with anything else (telnet, nc, etc.) while that port was blocked, you’d 
> > have got the same error.
> 
> fair enough, I hadn't actually tried (or considered) that, but you're right:
> I just tested with nc towards another firewalled port, and it does indeed 
> claim 'no route to host', so...
> 
> > Any changes to make the message more accurate and informative would 
> > have to take place in the kernel and the C library.  As you might have 
> > guessed, we don’t maintain either and are bound by their behavior.  
> > :-)
> 
> heh, yeah :)
> 
> It's pretty far from optimal, but there are so many ways things can fail, 
> that it's probably not easy to return accurate information in many 
> situations - but I would personally have preferred a more generic message.
> 
> "no route to host" *is* pretty specific, and does suggest a routing issue.
> But at least now I know.
> 
> > 
> >     Maybe, actually, a couple of pointers on how to submit bug reports?
> >     
> > Asking on the perfsonar-users is a good start.  If you’re positive you’ve 
> > found a bug, you can also drop us a line directly on the 
> > perfsonar-developers list.  The perfSONAR project on GitHub 
> > (https://github.com/perfsonar) is divided up into many sub-projects, each 
> > with its own issue tracker, so I don’t recommend submitting bugs directly 
> > there unless you know which component is the problem.
> 
> Thanks for this :)
> 
> br
> /jon
> 
> 
> -- 


--

Attachment: signature.asc
Description: PGP signature