VS Code randomly starts listening on high port on 0.0.0.0 - visual-studio-code

VS code often starts listening on a random high port on all interfaces.
$ lsb_release -d
Description: Ubuntu 22.04 LTS
$ code --version
1.67.2
c3511e6c69bb39013c4a4b7b9566ec1ca73fc4d5
x64
$ sudo ss -ltpn | grep code
LISTEN 0 511 *:33333 *:* users:(("code",pid=75602,fd=52))
In VS code developer tools console:
CRITI Extension 'ms-vsliveshare.vsliveshare' wants API proposal 'notebookDocumentEvents' but that proposal DOES NOT EXIST. Likely, the proposal has been finalized (check 'vscode.d.ts') or was abandoned.
log.ts:313
ERR UnboundLocalError: local variable 'start_index' referenced before assignment: Error: UnboundLocalError: local variable 'start_index' referenced before assignment
at /home/user/.vscode/extensions/ms-python.python-2022.8.0/out/client/extension.js:2:2107873
at /home/user/.vscode/extensions/ms-python.python-2022.8.0/out/client/extension.js:2:2108167
at Immediate.<anonymous> (/home/user/.vscode/extensions/ms-python.python-2022.8.0/out/client/extension.js:2:2108529)
at processImmediate (node:internal/timers:464:21)
log.ts:313
ERR Error: File not found
at g.handleSetInputError (vscode-file://vscode….main.js:2701:95592)
at async g.setInput (vscode-file://vscode….main.js:2701:94832)
at async doSetInput (vscode-file://vscode…p.main.js:2699:6429)
at async doOpenEditor (vscode-file://vscode…p.main.js:2699:4791)
at async d.openEditor (vscode-file://vscode…p.main.js:2699:3783)
at async vscode-file://vscode….main.js:2906:16950
at async bi.openAnything (vscode-file://vscode….main.js:2712:17542)
I have not been able to reproduce whenever the Microsoft Python extension (Python
v2022.8.0) was disabled, so it might be related to that. There is an error in the console related to ms-python, but I do not immediately see how it would lead to a port being opened, especially not on 0.0.0.0.
The following shows nothing:
$ sudo tcpdump -i any port 33333
The question is what causes this port to be opened (and how to avoid this).
In the process explorer of VS code it shows that the process that opened the port is 'extensionHost'.

Related

Error: EADDRINUSE connect EADDRINUSE 127.0.0.1:50596 when running e2e test suit on VS code

When I run e2e test suites on VS code getting an unusual error - Error: EADDRINUSE connect EADDRINUSE 127.0.0.1:50596 don't know how to solve this, its happening to all instance and failing all test cases with same error. when I debug this in dev tools getting this error in console log (node:16612) [DEP0005] Deprecation Warning: Buffer() is deprecated due to security and usability issues. Please use the buffer. From() methods instead.
(Use Code --trace-deprecation … to show where the warning was created)
Node version >v11.15.0**
NPM. version >6.7.0
Chrome browser
This error Error: EADDRINUSE connect EADDRINUSE 127.0.0.1:50596 means the address 127.0.0.1:50596 is already used.
You can find out what's using the port 50596, and then kill the process (see https://www.printsupportcenter.com/hc/en-us/articles/115003386949-Determine-which-program-uses-or-blocks-a-port):
Windows:
netstat -ano -p tcp | find "50596"
Linux/Mac:
sudo netstat -ano -p tcp | grep ":50596"
These previous commands will give you the Process IDentifier (PID), which you can then use to kill your process:
Windows:
taskkill /PID <pid_number>
Linux/Mac:
kill <pid_number>

Can't connect remotely using Remote-SSH: "spawn UNKNOWN"

I'm trying to remotely connect to a server (running on Ubuntu 16.04.7 LTS) through VSCode (started on WSL).
I've set the path to my WSL Config file (with the SSH keys inside) in VSCode Remote-SSH.
I can reach and connect to the server through the terminal as well as the VSCode terminal.
Yet, when trying to connect through Remote-SSH I'm getting the message
Failed to connect to the remote extension host server (Error: spawn UNKNOWN)
with the following error log:
[13:50:42.906] Log Level: 2
[13:50:42.922] remote-ssh#0.56.0
[13:50:42.922] win32 x64
[13:50:42.925] SSH Resolver called for "ssh-remote+<net>.net", attempt 1
[13:50:42.925] SSH Resolver called for host: <net>.net
[13:50:42.926] Setting up SSH remote "<net>.net"
[13:50:42.970] Using commit id "<CommitID>" and quality "stable" for server
[13:50:42.974] Install and start server if needed
[13:50:44.876] Checking ssh with "ssh -V"
[13:50:44.888] Finding installed ssh failed: spawn UNKNOWN
[13:50:44.897] Resolver error: Error: spawn UNKNOWN
at ChildProcess.spawn (internal/child_process.js:394:11)
at Object.spawn (child_process.js:549:9)
at c:\Users\<user>\.vscode\extensions\ms-vscode-remote.remote-ssh-0.56.0\out\extension.js:1:242426
at new Promise (<anonymous>)
at q (c:\Users\<user>\.vscode\extensions\ms-vscode-remote.remote-ssh-0.56.0\out\extension.js:1:242347)
at k (c:\Users\<user>\.vscode\extensions\ms-vscode-remote.remote-ssh-0.56.0\out\extension.js:1:242298)
at _ (c:\Users\<user>\.vscode\extensions\ms-vscode-remote.remote-ssh-0.56.0\out\extension.js:1:245580)
at P (c:\Users\<user>\.vscode\extensions\ms-vscode-remote.remote-ssh-0.56.0\out\extension.js:1:245741)
at O (c:\Users\<user>\.vscode\extensions\ms-vscode-remote.remote-ssh-0.56.0\out\extension.js:1:242117)
at C (c:\Users\<user>\.vscode\extensions\ms-vscode-remote.remote-ssh-0.56.0\out\extension.js:1:242026)
at Object.t.generateMultiLineCommand (c:\Users\<user>\.vscode\extensions\ms-vscode-remote.remote-ssh-0.56.0\out\extension.js:1:243396)
at q (c:\Users\<user>\.vscode\extensions\ms-vscode-remote.remote-ssh-0.56.0\out\extension.js:127:107623)
at c:\Users\<user>\.vscode\extensions\ms-vscode-remote.remote-ssh-0.56.0\out\extension.js:127:105016
at processTicksAndRejections (internal/process/task_queues.js:94:5)
at async Object.t.withShowDetailsEvent (c:\Users\<user>\.vscode\extensions\ms-vscode-remote.remote-ssh-0.56.0\out\extension.js:127:110096)
at async Object.t.resolve (c:\Users\<user>\.vscode\extensions\ms-vscode-remote.remote-ssh-0.56.0\out\extension.js:127:108158)
at async c:\Users\<user>\.vscode\extensions\ms-vscode-remote.remote-ssh-0.56.0\out\extension.js:127:143767
[13:50:44.908] ------
Already tried setting up manually the vscode server remotely as suggested here
Thanks in advance for any help!
Seems things got messed up with the update.
I fixed it by reinstalling the Remote SSH extension: ms-vscode-remote.remote-ssh and reloading as you will be instructed to do.
I also just installed the entire Remote Development extension: ms-vscode-remote.vscode-remote-extensionpack and reloaded vscode as instructed by vscode.
Before this though, I deleted (rm -rf) the contents of /home/<your_username>/.vscode-server/ bin/ and data/
Had the same problem.
After trying everything, the only thing that worked 100% was just killing vs-code and opening it again.

Cannot send command IR with HotPI

I bought a HotPi a while ago, and decided to use it. So I followed the procedure to configure the IR and after a few hours I was able to IR signals on my Raspberry 1.
But my purpose here is to send IR signals, which I tried, without any luck.
So this is the command I try to do (just for test):
irsend SEND_START devinput KEY_POWER ; sleep 3
And this is what lircd tells me:
lircd-0.9.4c[907]: Notice: accepted new client on /var/run/lirc/lircd
lircd-0.9.4c[907]: Info: Cannot configure the rc device for /dev/lirc0
lircd-0.9.4c[907]: Error: invalid send buffer
lircd-0.9.4c[907]: Error: this remote configuration cannot be used to transmit
lircd-0.9.4c[907]: Error: error processing command: SEND_START devinput KEY_POWER
lircd-0.9.4c[907]: Error: transmission failed
lircd-0.9.4c[907]: Info: removed client
Edit:
It seems I'm not using the good drivers. According to the HotPi documentation, I'm suppose to use lirc-rpi, which I'm suppos to install with
sudo modprobe lirc-rpi
Which, at least, doesn't return an error. But trying to configure the interface tells me that the driver doesn't exist:
pi#raspberrypi:~ $ mode2 --driver lirc-rpi --device /dev/lirc0
Driver `lirc-rpi' not found. (Missing -U/--plugins option?)
Available drivers:
accent
alsa_usb
asusdh
atilibusb
atwf83
audio
audio_alsa
awlibusb
bte
bw6130
commandir
creative
creative_infracd
default
devinput
dfclibusb
dsp
dvico
ea65
file
ftdi
ftdi-exp
ftdix
girs
i2cuser
irlink
irtoy
livedrive_midi
livedrive_seq
logitech
macmini
mouseremote
mouseremote_ps2
mp3anywhere
mplay
mplay2
pcmak
pinsys
pixelview
samsung
sb0540
silitek
slinke
sonyir
srm7500libusb
tira
tira_raw
udp
uirt2
uirt2_raw
usb_uirt_raw
usbx
zotac
Here is no info what lirc version you are using. There are vast differences between the legacy 0.9.0 still used in some distros and modern lirc.
That said, the logs seems pretty clear. You are using the devinput driver, right? This driver does not support sending data, reflecting the fact that also the kernel doesn't.
You then need to use another driver - first stop might be the default one. If/when using this other driver, you need another lircd.conf.
Please refer to http://lirc.org/html/configuration-guide.html
EDIT: Ah, lirc-0.9.4c says the log. Sorry, my bad. The reply should still be valid, though.
When you record the remote, use:
irrecord -d /dev/lirc0 -f name.conf
The -f uses raw mode. This then worked for me on the transmit side, before I got same error as you.

Orion Context Broker: reset by peer when calling updateContext

Just after the install of the Context Broker I've tried to test it creating a new entity as described in the session Entity Creation of https://forge.fi-ware.org/plugins/mediawiki/wiki/fiware/index.php/Publish/Subscribe_Broker_-_Orion_Context_Broker_-_User_and_Programmers_Guide, but I'm getting a "connection reset by peer" error.
The log doesn't seem say anything, even I raised the level of traces with -t 0-255 option.
Aditional info:
$ contextBroker --version
0.14.0
$ ps aux | grep context
/usr/bin/contextBroker -port 1026 -logDir /var/log/contextBroker -pidpath /var/log/contextBroker/contextBroker.pid -dbhost localhost -db orion -t 0-255
The issue was fixed updating the Context Broker to a newer version, in my case to version 0.14.1, which can be found here: http://repositories.testbed.fi-ware.org/repo/rpm/x86_64/.
I can't say exactly what was wrong, since after updating everything was working fine.

python-memcache memcached -- I installed on centos virtualbox but it get/set never seem to work

I'm using python. I did a yum install memcached followed by a easy_install python-memcached
I used the simple test program from the Help(memcache). When I wasn't getting the proper answers I threw in some print statements:
[~/test]$ cat m2.py
import memcache
mc = memcache.Client(['127.0.0.1:11211'], debug=0)
x = mc.set("some_key", "Some value")
print 'Just set a key and value into the cache (suposedly)'
value = mc.get("some_key")
print 'Just retrieved that value from the cache using the key'
print 'X %s' % x
print 'Value %s' % value
[~/test]$ python m2.py
Just set a key and value into the cache (suposedly)
Just retrieved that value from the cache using the key
X 0
Value None
[~/test]$
The question now is, what have I failed to do in my installation? It appears to be working from an API perspective but it fails to put anything into the memcache share area.
I'm using a virtualbox vm running centos
[~]# cat /proc/version
Linux version 2.6.32-358.6.2.el6.i686 (mockbuild#c6b8.bsys.dev.centos.org) (gcc version 4.4.7 20120313 (Red Hat 4.4.7-3) (GCC) ) #1 SMP Thu May 16 18:12:13 UTC 2013
Is there a daemon that is supposed to be running? I don't see an obvious named one when I do a ps.
I tried to get pylibmc installed on my vm but was unable to find a working installation so for now will see if I can get the above stuff working first.
I discovered if i ran straight from the python console GUI i get a bit more output if I set debug=1
>>> mc = memcache.Client(['127.0.0.1:11211'], debug=1)
>>> mc.stats
{}
>>> mc.set('test','value')
MemCached: MemCache: inet:127.0.0.1:11211: connect: Connection refused. Marking dead.
0
>>> mc.get('test')
MemCached: MemCache: inet:127.0.0.1:11211: connect: Connection refused. Marking dead.
When I try to use per the example telnet to connect to the port i get a connection refused:
[root#~]# telnet 127.0.0.1 11211
Trying 127.0.0.1...
telnet: connect to address 127.0.0.1: Connection refused
[root#~]#
I tried the instructions I found on the net for configuring telnet so localhost wouldn't be disabled:
vi /etc/xinetd.d/telnet
service telnet
{
flags = REUSE
socket_type = stream
wait = no
user = root
server = /usr/sbin/in.telnetd
log_on_failure += USERID
disable = no
}
And then ran the commands to restart the service(s):
service iptables stop
service xinetd stop
service iptables start
service xinetd start
service iptables stop
I ran with both cases (iptables started and stopped) but it has no effect. So I am out of ideas. What do I need to do to make it so the PORT will be allowed? if that is the problem?
Or is there a memcached service that needs to be running that needs to open up the port ?
well this is what it took to get it working: ( a series of manual steps )
1) su -
cd /var/run
mkdir memcached # this was missing
In the memcached file I added "-l 127.0.0.1" to the OPTIONS statement. It's apparently a listen option. Do this for steps 2 & 3. I'm not certain which file is actually used at runtime.
2) cd /etc/sysconfig
cp memcached memcached.old
vi memcached
3) cd /etc/init.d
cp memcached memcached.old
vi memcached
4) Try some commands to see if the server starts now
/etc/init.d/memcached start
/etc/init.d/memcached status
/etc/init.d/memcached stop
/etc/init.d/memcached restart
I tried opening a browser, but it never seemed to actually display anything so I don't really know how valid this approach is. I'm not running apache or anything like this so perhaps its not relevant to my cause. Perhaps I would have to supply a ?key=blah or something.
5) http://127.0.0.1:11211
6) Now it should be ready to go. If one runs the test shown with the following it should work. At least it did for me. doing the help(memcache) will display a simple program. just paste that in and it should work just fine.
[~]$ python
>>> import memcache
>>> help(memcache)