# LinkConnect errors while connecting to remote kernel. Interactive commands fail

For a while I have a set-up running a Mathematica front-end on a Macbook and a remote kernel on a Linux (CentOS) computer. Recently something changed and I have issues with the remote kernel but I cannot pinpoint it. I upgraded MacOS to 10.12.4 and also Mathematica to 11.1 on both systems.

When I start the remote kernel, I get the following message :

LinkConnect::linkc: Unable to connect to LinkObject[53745@172.16.9.115,53746@172.16.9.115,56,2]. LinkConnect::linkc: Unable to connect to LinkObject[53743@172.16.9.115,53744@172.16.9.115,57,3]. LinkObject::linkn: Argument LinkObject[53743@172.16.9.115,53744@172.16.9.115,57,3] in MathLinkAddSharingLink[LinkObject[53743@172.16.9.115,53744@172.16.9.115,57,3],MathLinkAllowPreemptive->True,MathLinkLinkSwitchPre->FrontEndPrivatePreContextSwitchIn,MathLinkLinkSwitchPost->FrontEndPrivatePreContextSwitchOut] has an invalid LinkObject number; the link may be closed.

At first everything seems to work. I can do computations and plot graphics. However, any dynamic or interactive (e.g. Manipulate) command fails. So I presume the failed link is used for this.

The Macbook is effectively listening to the ports as can be seen from the output of lsof :

java 2987 peterb 62u IPv4 0xdbd5c28e4af9a547 0t0 TCP macbook-pro.sky.lan:53743 (LISTEN) java 2987 peterb 63u IPv4 0xdbd5c28e519a1357 0t0 TCP macbook-pro.sky.lan:53744 (LISTEN) java 2987 peterb 64u IPv4 0xdbd5c28e5176186f 0t0 TCP macbook-pro.sky.lan:53745 (LISTEN) java 2987 peterb 146u IPv4 0xdbd5c28e46850a5f 0t0 TCP macbook-pro.sky.lan:53746 (LISTEN)

A port scan of the Macbook done on the Linux computer confirms that the ports are open. So I does not seem to be a network or firewall issue.

So I am stuck now and out of ideas where to look (not really an expert in these link issues).

Peter

## 1 Answer

I had the same problem today, with exactly the same error message, of mathematica being not able to connect to the kernels, which is why I ended up on your question.

In my case it had nothing to do with the process of connecting to remote kernels as I am simply using vnc to work on that machine.

I had this problem now for several days. Today while having "top" in a shell running in the background I could see that there were still WolframKernels popping up to the top, although I had certainly closed the program.

So I used

ps -u username

in the shell to see what kind of kernels they were. I found a list of kernels and some of them had "defunct" written behind them.

Using then

ps -ef | grep defunct

will show all processes together with two numbers, the PID and PPID.

Then type

kill -9 PID PPID

and all the processes belonging to the PPID will be killed.

It seems that due to whatever there will be zombified processes remaining in the background and then somehow they interfere with new kernels, either by blocking licenses or whatever. I don't have enough computer knowledge to exactly understand what is going on.

I just described what helped me and maybe the same procedure works for you or anybody else. It is probably not the best solution, but now my kernels run again nicely.

• This answer may not address the problem presented in the question, but it seems useful anyway. – bbgodfrey Sep 12 '17 at 1:29