Vs code lang server won't start

vscode language server won’t start error msg is:

ERROR: LoadError: IOError: connect: permission denied (EACCES)
 [1] wait_connected(x::Base.PipeEndpoint)
   @ Sockets C:\Users\yjr\.julia\juliaup\julia-1.10.4+0.x64.w64.mingw32\share\julia\stdlib\v1.10\Sockets\src\Sockets.jl:528
 [2] connect
   @ C:\Users\yjr\.julia\juliaup\julia-1.10.4+0.x64.w64.mingw32\share\julia\stdlib\v1.10\Sockets\src\Sockets.jl:563 [inlined]
 [3] connect
   @ C:\Users\yjr\.julia\juliaup\julia-1.10.4+0.x64.w64.mingw32\share\julia\stdlib\v1.10\Sockets\src\PipeServer.jl:103 [inlined]
 [4] serve(args::String; is_dev::Bool, crashreporting_pipename::String)
   @ VSCodeServer c:\Users\yjr\.vscode\extensions\julialang.language-julia-1.79.2\scripts\packages\VSCodeServer\src\VSCodeServer.jl:113
 [5] top-level scope
   @ c:\Users\yjr\.vscode\extensions\julialang.language-julia-1.79.2\scripts\terminalserver\terminalserver.jl:45
in expression starting at c:\Users\yjr\.vscode\extensions\julialang.language-julia-1.79.2\scripts\terminalserver\terminalserver.jl:20

Any ideas welcome

Perhaps there is some julia process still running which blocks the socket?
Close all Julia windows, open the Task Manager and kill all julia processes still running, if any.

I tried it but no luck I had only one julia process corresponding to the one giving the error. I think it is linked to some rights that are too stringent but I’ve to find what exactly so that I can tell the IT guy where to elevate privilege.

This would be next step I would have recommended.
It works probably with admin rights, but you still don’t know why.

I use Process Monitor from the Sysinternals suit to hunt down errors like this.(Sysinternals - Sysinternals | Microsoft Learn) Your IT guy probably know.

Or @davidanthoff can tell us, which socket this is and where some access rights needs to be given.

I had a similar problem the other day. My organisation’s IT policies suddenly blocked something and so julia couldn’t start. I presume that they did some kind of update overnight. They were quickly able to sort things out - even though they didn’t have an exact diagnosis:

There is no information that states specifically what is being blocked but we do have a suspicion. As a test I have added you to a group that excludes you from a particular policy and have forced a synch with your device.

This worked for me and I’m back in business! I’m afraid I don’t know the particular policy that caused the problem in the first place, though.

1 Like

Hm, we generate a new pipe name with a uuid in it every time, so it can’t be a name conflict…

I also doubt that it is a general not-admin problem, I assume we would have run into that a long time ago, plus as far as I know named pipes should work perfectly fine for non-admin accounts.

So not sure right now, I’ll keep thinking…

1 Like

I agree that it’s probably something special. I pinged expecting an answer like this from someone who knows. It’s still very valuable information for OPs IT “guys” so they can check their windows security policies.

Finally I was able to make it run by disabling the firewall during server start…

1 Like

Some rules are too restrictive. Or it’s missing some rules to overcome overly restrictive rules.
This is not a problem as long as corporate IT is open to changes on the policies if needed.

So I asked IT is they could clarify the rule that was blocking my use of julia:

I cannot go into details of our security policies and also I cannot leave you in there because it is a huge security risk.
I will be taking you out of that policy and instead I will be creating an exemption for the specific piece of software to enable you to continue working.
Further consideration will need to be given as to whether we can continue to allow that software within the organisation or whether there is something more suitable that poses less of a risk.

I would be extremely unhappy to lose the use of julia and go back to square one with something else.

1 Like

Security IS important. But productive work should not be made impossible for security reasons. This is a natural conflict in a corporate environment, but if security beats productivity there will soon be no security needed anymore because there is nothing left to be secured.

But the good news is, they let you work and they are thinking about it how to find a good compromise as far as I can tell from the little I know.

So in general I think the policy they have is too restrictive. I made extra sure to not use sockets and ports, so that none of the communication channels is ever accessible from a network. Why they would be blocking local named pipe communication is beyond me, TBH…

1 Like