Closed sm3136 closed 1 year ago
OK, that is strange.
I don't have RHEL7 at the moment, just a current Archlinux and a virtual Ubuntu. There I could not yet observe this behavior and also not reproduce.
Normally vscode is responsible to start up and shut down the language-server, or if it doesn't shut down the process is killed. maybe vscode server does it differently because it still has some sessions open or something?
In you picture I see vscode-server,
vscode-server is from users who SSH into the RHEL7. This server also host virtual desktops which is how we have multiple users who use vscode on it. From what I know, other extensions are closing out but RobotCode appears to be remaining open. This leads me to believe that vscode & vscode-server is properly shutting down / terminating, but the RobotCode process is getting stranded.
ok, tried a little.
at first sight it seems that when VSCode updates the extension without disposing or better shutting down the server.
In your screenshot, for the most part, different versions of robotcode are listed. Can you confirm that these versions are all from different users or is it always the same user?
As a workaround please try to change the robotcode.languageServer.mode
in the VSCode settings to stdio
for global or remote. (Just search in the settings for robotcode.languageServer.mode
) Then the communication between VSCode and the Python server part of RobotCode runs over normal pipes, when the pipe is closed, the server should close too. (Before that please restart the Linux server or kill all processes with RobotCode in the name).
If this works, can you give me some feedback?
I am in the process of splitting up the Python Server Process and outsourcing many parts of it into individual short-running processes. The test discovery is already outsourced in the last version. This should reduce the load on the language server part and speed up a lot of things and also prevent occasional deadlocks. Maybe that is also a reason for it. But this still takes a little while.
It appears that some of those were different versions for the same user. It does appear that the there are multiple of the same version for the same user as well. Today I will implement that settings change and see if that yields different results for us.
Okay, so little bit of an update. After setting robotcode.languageServer.mode
to stdio
it appears that it does not spawn tons of new processes, but when vscode (and vscode-server) exit it appears to leave open a process (.vscode/extensions/d-biehl.robotcode-0.37.1/bundled/tool/language_server --stdio
). It does seem that this process is reused luckily so this seems to work for now.
ok, thanks, let's keep an eye on that. I'll take a closer look in the next days and report back here.
Implement something that monitors the parent process from which the extension is started. When this process is terminated or whatever, the robotcode language server is also terminated.
You can reset the robotcode.languageServer.mode
to the default pipe
, or delete the setting in settings.json
and check if it works and the problem is gone. If not you can repoen this issue.
But wait until the next release is published.
Describe the bug It appears that the extension is not terminating when VSCode terminates. The team I am part of uses this extension for out testing suite and we have found that processes remain active days or months after we have closed out of VSCode. It is worth mentioning that our test suite is large (250+ files).
To Reproduce
ps ef | grep robotcode
and you will see it still remainsExpected behavior I am expecting that it will terminate after we exit VSCode as to prevent process build up.
Screenshots/ Videos
Desktop (please complete the following information):