From time to time, the connection with SG Desktop will die and I will no longer have TK menus in SG. This will happen when I have been working fine for a while then I’ll go to lunch or something and come back and am met with this:
- MacOS Sonoma 14.1.1
- SG Desktop 1.8.0 is open and my Project is selected.
- I have no proxy or firewall set up
- I am not connected to any VPN
- When it happens in Chrome, the same behavior is also visible in Safari
So I try the following:
- Do a full browser page refresh
- restart SG Desktop and do a full browser page refresh
- restart Chrome
- Quit both SG Desktop and Chrome and start them back up again.
- Try in another browser like Safari
None of this works.
When I go to https://shotgunlocalhost.com:9000/ I’m met with an error page in Chrome:
This site can’t provide a secure connection
shotgunlocalhost.com sent an invalid response.
ERR_SSL_PROTOCOL_ERROR
I open up a terminal and try to get more info with curl
$ curl https://shotgunlocalhost.com:9000/ -v
* Trying 127.0.0.1:9000...
* Connected to shotgunlocalhost.com (127.0.0.1) port 9000 (#0)
* ALPN: offers h2,http/1.1
* (304) (OUT), TLS handshake, Client hello (1):
* CAfile: /etc/ssl/cert.pem
* CApath: none
* LibreSSL/3.3.6: error:1404B42E:SSL routines:ST_CONNECT:tlsv1 alert protocol version
* Closing connection 0
curl: (35) LibreSSL/3.3.6: error:1404B42E:SSL routines:ST_CONNECT:tlsv1 alert protocol version
In the past when this happens, I can restart my machine and it will start working again. But why do I have to restart my machine just to get it to work again? Incredibly inconvenient especially when I’m in the middle of several tasks.
Any insights from the masses here?
(I did see this unanswered post but the details were light and there were no responses)
1 Like
I tried these additional steps:
- rebooting machine
- deleting the Shotgun cache
~/Library/Caches/Shotgun
- re-installing SG Desktop v1.8
None of them worked. 
Aha!
Since the error was an SSL error, I checked to see if something else was running on port 9009:
$ sudo lsof -i :9000
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
python3.9 40323 kp 51u IPv4 0xec748e718a40ec09 0t0 TCP localhost:cslistener (LISTEN)
Shotgun 40663 kp 52u IPv4 0xec748e718a3ed9c9 0t0 TCP *:cslistener (LISTEN)
I see Shotgun is listening, but also see there’s another python process listening on it as well. Encouraging…
So I looked up that process id:
$ ps aux | grep 40323
kp 3255 0.0 0.0 36062700 3192 ?? S 7:04PM 0:01.93 /Users/kp/dev/sandbox/.venv/bin/python -m ipykernel_launcher --f=/Users/kp/Library/Jupyter/runtime/kernel-v2-2308AmpB0sKxzMdj.json
I have a VScode window open where I’m running some tests in a Jupyter notebook. It appears that the server started on port 9000 and that is what was blocking SG Desktop from connecting.
Once I shut that down, my SG Desktop browser integration is working again.
I tried setting the default port for Jupyter notebook in the VScode settings with:
"jupyter.jupyterCommandLineArguments": [
"--NotebookApp.port=9999"
],
But this didn’t seem to work. The best workaround I can see is to ensure you start SG Desktop first and then start your Jupyter notebook as the ipython kernel will find an open port to run on if 9000 is already taken. Whereas SG Desktop just blindly listens on port 9000 even if something else is already listening.
Hope this helps someone in the future. 
3 Likes
Thank you so much for posting the solution KP, this is very helpful.
Cheers
It’s work pointing out that this same issue plagues the ShotGrid Application Session Launcher. If you’re trying to login to SG Desktop using the ShotGrid Application Session Launcher option and your web browser says either the request was invalid, or you approve the request and nothing happens… closing your Jupyter notebook server will resolve things.
