-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
flux-relay: initialize log prefix to hostname when possible #4454
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good idea! This is fine as is, although I did make some nitpicky comments about gethostname()
that likely won't amount to much improvement.
src/cmd/builtin/relay.c
Outdated
* for end users that may be uknowningly using flux-relay as part of | ||
* the ssh connector. | ||
*/ | ||
if (gethostname (hostname, MAXHOSTNAMELEN) < 0) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
By my read of gethostname(1) the length parameter should be the size of the buffer not the maximum string length, so use MAXHOSTNAMELEN + 1, or maybe better, sizeof (hostname)
here?
Also, not sure if this is important but the man page references HOST_NAME_MAX not MAXHOSTNAME. (Might be an alias but the former is apparently the POSIX one). Looking around our code base we use both :-(
Another thought is to use "unknown-host" or similar as the fallback if gethostname()
fails (very unlikely). Could just statically initialize hostname[] to that value and avoid the duplicate call to log_init()
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great suggestions!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I did also see the HOST_NAME_MAX
reference in the man page as well, but when I spot checked our codebase I saw use of MAXHOSTNAMELEN
. Rather than fix it now, I chose MAXHOSTNAMELEN
for consistency (though I guess I missed the uses of HOST_NAME_MAX
)
fa9df7f
to
f7142ac
Compare
Problem: Users almost always use flux-relay indirectly via the ssh connector by specifying a ssh:// URI or a high-level URI which resolves to an ssh URI. Therefore, the flux-relay log prefix on errors from this utility may not be useful to users. If possible, use the hostname as the log prefix. This will not only remove the possibly confusing flux-relay prefix, but will allow pinpointing the actual host on which the flux-relay is failing to, for example, open a local connector socket. In the unlikely event that gethostname(3) fails, then fall back to "uknown-host".
f7142ac
to
bdce25e
Compare
@garlick, I addressed your comments. I switched to
Therefore it seems like existence of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sheesh, they make a simple thing so complicated.
Oh well, this looks good to me!
Thanks! Setting MWP. |
Codecov Report
@@ Coverage Diff @@
## master #4454 +/- ##
=======================================
Coverage 83.34% 83.34%
=======================================
Files 400 400
Lines 67258 67226 -32
=======================================
- Hits 56055 56032 -23
+ Misses 11203 11194 -9
|
When the ssh connector fails to connect to a remote uri, but the ssh was successfully able to execute
flux-relay
, an error such as the following is displayedThe
flux-relay
prefix probably isn't all that helpful for users, and may be confusing, sinceflux-relay
was only indirectly run as part of thessh
connector. Instead it may be more useful to use the hostname as the command prefix. This way, the user is made aware of the host on which the local connection failed e.g