Skip to content
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

RuntimeError: SOCKS network proxying failed to start... #1141

Closed
ivan046 opened this issue Oct 4, 2019 · 4 comments
Labels
Projects

Comments

@ivan046
Copy link

@ivan046 ivan046 commented Oct 4, 2019

What were you trying to do?

Tried to start telepresence via telepresence --method inject-tcp --context dev --namespace t1 with or without sudo/--expose /--run-shell

What did you expect to happen?

Started normally

What happened instead?

A message: Looks like there's a bug in our code. Sorry about that!
and a traceback below..

Automatically included information

Command line: ['/usr/bin/telepresence', '--method', 'inject-tcp', '--context', 'dev', '--namespace', 't1', '--run-shell', '--expose', '9099']
Version: 0.102
Python version: 3.5.2 (default, Jul 10 2019, 11:58:48) [GCC 5.4.0 20160609]
kubectl version: Client Version: v1.16.0 // Server Version: v1.14.7
oc version: (error: [Errno 2] No such file or directory: 'oc')
OS: Linux PackardBell 4.15.0-64-generic #73~16.04.1-Ubuntu SMP Fri Sep 13 09:56:18 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

Traceback (most recent call last):
  File "/usr/bin/telepresence/telepresence/cli.py", line 135, in crash_reporting
    yield
  File "/usr/bin/telepresence/telepresence/main.py", line 77, in main
    runner, remote_info, env, socks_port, ssh, mount_dir, pod_info
  File "/usr/bin/telepresence/telepresence/outbound/setup.py", line 50, in launch
    return launch_inject(runner_, command, socks_port, env)
  File "/usr/bin/telepresence/telepresence/outbound/local.py", line 101, in launch_inject
    torsocks_env = set_up_torsocks(runner, socks_port)
  File "/usr/bin/telepresence/telepresence/outbound/local.py", line 71, in set_up_torsocks
    raise RuntimeError("SOCKS network proxying failed to start...")
RuntimeError: SOCKS network proxying failed to start...

Logs:

: twisted.internet.error.DNSLookupError: DNS lookup failed: kubernetes.default.svc.cluster.local.
  24.6  13 | 
  24.7  49 | Traceback (most recent call last):
  24.7  49 |   File "<string>", line 1, in <module>
  24.7  49 | socket.gaierror: [Errno -4] Non-recoverable failure in name resolution
  24.8 TEL | [49] exit 1 in 0.52 secs.
  24.9 TEL | [50] Running: torsocks python3 -c 'import socket; socket.socket().connect(('"'"'kubernetes.default.svc.cluster.local'"'"', 443))'
  25.2  13 | 2019-10-04T20:38:48+0000 [-] Unhandled Error
  25.2  13 | 	Traceback (most recent call last):
  25.2  13 | 	Failure: twisted.internet.error.DNSLookupError: DNS lookup failed: kubernetes.default.svc.cluster.local.
  25.2  13 | 
  25.3  50 | Traceback (most recent call last):
  25.3  50 |   File "<string>", line 1, in <module>
  25.3  50 | socket.gaierror: [Errno -4] Non-recoverable failure in name resolution
  25.3 TEL | [50] exit 1 in 0.46 secs.
  25.3 TEL | END SPAN local.py:42(set_up_torsocks)   15.0s

@ark3

This comment has been minimized.

Copy link
Contributor

@ark3 ark3 commented Oct 7, 2019

Sorry about the crash!

Telepresence does a connect check to make sure DNS and forwarding are working. In your case here, this check seems to have failed on DNS. If you try that hostname lookup manually in your cluster, does it work?

On my cluster:

$ kubectl run dns-check -it --rm --image=alpine --restart=Never nslookup kubernetes.default.svc.cluster.local
nslookup: can't resolve '(null)': Name does not resolve

Name:      kubernetes.default.svc.cluster.local
Address 1: 10.43.0.1 kubernetes.default.svc.cluster.local
pod "dns-check" deleted

Thank you for your help.

@ivan046

This comment has been minimized.

Copy link
Author

@ivan046 ivan046 commented Oct 12, 2019

Hello! Thanks for your answer! The problem is that our cluster default name and thus default domain zone is not "cluster.local "
Is it t possible to provide telepresence a custom kubernetes api service address or at least force it to check a shorter one (kubernetes.default.svc) s it's cluster zone's agnostic?

@ivan046

This comment has been minimized.

Copy link
Author

@ivan046 ivan046 commented Oct 13, 2019

@ark3 ^^

@ark3 ark3 added the enhancement label Oct 24, 2019
@ark3 ark3 added this to To do in Tel Tracker via automation Oct 24, 2019
@ark3

This comment has been minimized.

Copy link
Contributor

@ark3 ark3 commented Oct 24, 2019

Based on this and #1161 I think switching to kubernetes.default is the way to go.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
2 participants
You can’t perform that action at this time.