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

Redirect redir errors to /dev/null #51

Closed
fgrehm opened this Issue Apr 9, 2013 · 6 comments

Comments

Projects
None yet
3 participants
@fgrehm
Owner

fgrehm commented Apr 9, 2013

When no process is listening on the forwarded port on the guest container redir spills up some target: connect: Connection refused errors on the terminal

@fgrehm fgrehm closed this in 2e14c97 Apr 10, 2013

@dergachev

This comment has been minimized.

Show comment
Hide comment
@dergachev

dergachev Jun 20, 2013

@fgrehm,

This change also completely masks errors like redir package not being installed. Instead port forwarding fails, while "vagrant reload" output looks perfect. (Just got bitten by this).

Also if redir isn't able to bind to a port, then it'll print out server: bind: Address already in use which seems useful.

Is there a better way to handle this? At least, is it possible to trap errors from launching redir, currently done using Kernel.spawn?

For future Googlers: At first, I mistook my problem to be the same as the one mentioned in this tutorial:
http://taoofmac.com/space/HOWTO/Vagrant#port-forwarding

For my notes: I was able to reproduce the target: connect: Connection refused message by doing the following:

bash$ screen
screen1$ sudo redir --laddr=127.0.0.1 --lport=9090 --cport=12345 --caddr=10.0.3.226    # nothing listening on 12345
screen2$ curl localhost:9090    # this makes redir spit out 'target: connect: Connection refused' in screen1

dergachev commented Jun 20, 2013

@fgrehm,

This change also completely masks errors like redir package not being installed. Instead port forwarding fails, while "vagrant reload" output looks perfect. (Just got bitten by this).

Also if redir isn't able to bind to a port, then it'll print out server: bind: Address already in use which seems useful.

Is there a better way to handle this? At least, is it possible to trap errors from launching redir, currently done using Kernel.spawn?

For future Googlers: At first, I mistook my problem to be the same as the one mentioned in this tutorial:
http://taoofmac.com/space/HOWTO/Vagrant#port-forwarding

For my notes: I was able to reproduce the target: connect: Connection refused message by doing the following:

bash$ screen
screen1$ sudo redir --laddr=127.0.0.1 --lport=9090 --cport=12345 --caddr=10.0.3.226    # nothing listening on 12345
screen2$ curl localhost:9090    # this makes redir spit out 'target: connect: Connection refused' in screen1
@fgrehm

This comment has been minimized.

Show comment
Hide comment
@fgrehm

fgrehm Jun 20, 2013

Owner

hey @dergachev, tks for reaching out :)
yeah, I know, vagrant-lxc "user experience" is lacking some love =/ unfortunately I won't have that much of free time until july, so I'll just reopen this issue to keep it on the radar

Owner

fgrehm commented Jun 20, 2013

hey @dergachev, tks for reaching out :)
yeah, I know, vagrant-lxc "user experience" is lacking some love =/ unfortunately I won't have that much of free time until july, so I'll just reopen this issue to keep it on the radar

@fgrehm fgrehm reopened this Jun 20, 2013

@fgrehm

This comment has been minimized.

Show comment
Hide comment
@fgrehm

fgrehm Jun 20, 2013

Owner

@dergachev (hit submit too early) ... to keep it on the radar, I'll get back to you ASAP

Owner

fgrehm commented Jun 20, 2013

@dergachev (hit submit too early) ... to keep it on the radar, I'll get back to you ASAP

@fgrehm

This comment has been minimized.

Show comment
Hide comment
@fgrehm

fgrehm Jun 26, 2013

Owner

@dergachev so I gave this some thought today and I'm leaning towards keeping the redirect if we are not able to think of other issues because:

  • we'll detect whether redir is installed or not from #11
  • we'll detect if the port is in use and we'll handle collisions from #5
  • I can't think of another way of preventing target: connect: Connection refused from showing up and there is a huge chance that no process is listening on the forwarded port

what might be a good idea is to allow redirecting stdout and stderr to some log file, like using LXC_START_LOG_FILE for lxc-start stuff.

WDYT?

Owner

fgrehm commented Jun 26, 2013

@dergachev so I gave this some thought today and I'm leaning towards keeping the redirect if we are not able to think of other issues because:

  • we'll detect whether redir is installed or not from #11
  • we'll detect if the port is in use and we'll handle collisions from #5
  • I can't think of another way of preventing target: connect: Connection refused from showing up and there is a huge chance that no process is listening on the forwarded port

what might be a good idea is to allow redirecting stdout and stderr to some log file, like using LXC_START_LOG_FILE for lxc-start stuff.

WDYT?

@asharpe

This comment has been minimized.

Show comment
Hide comment
@asharpe

asharpe Jun 30, 2013

I vote for not pushing errors under the rug, especially when there are known cases where we want to see errors. Redirecting to a log file would be soo much better.

asharpe commented Jun 30, 2013

I vote for not pushing errors under the rug, especially when there are known cases where we want to see errors. Redirecting to a log file would be soo much better.

@fgrehm

This comment has been minimized.

Show comment
Hide comment
@fgrehm

fgrehm Jul 29, 2013

Owner

@dergachev @asharpe checking if redir is installed, forwarded ports collision handling and redir logging has been implemented and will be available from 0.5.0. keep an eye on #122 for more info.

Owner

fgrehm commented Jul 29, 2013

@dergachev @asharpe checking if redir is installed, forwarded ports collision handling and redir logging has been implemented and will be available from 0.5.0. keep an eye on #122 for more info.

@fgrehm fgrehm closed this Jul 29, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment