[1.1.1] Multiple IDE sessions blocked by lock file

Asked by Karl on 2017-10-17

We are running Sikuli on a Debian Linux VM from xrdp connected thin client machines, that all have local keyboards and monitors, but share the same Linux environment

We could without problem launch the Sikuli 1.0rc3 IDE on multiple remote thin clients.
When launching the Sikuli 1.1.1 IDE, Sikuli now creates a generic but user-owned lock file in /tmp, effectively blocking all other users from launching the Sikuli IDE on their own

Is there a way to make is possible to run multiple IDE instances by multiple users on multiple remote thin clients ?

Question information

Language:
English Edit question
Status:
Solved
For:
Sikuli Edit question
Assignee:
No assignee Edit question
Solved by:
Karl
Solved:
2017-10-23
Last query:
2017-10-23
Last reply:
2017-10-18
RaiMan (raimund-hocke) said : #1

As you might have already become aware of:
I implemented a switch, that allows to run multiple IDE's beginning with version 1.1.2 nightly
(see: https://raiman.github.io/SikuliX-2014/nightly.html)

Please test and give feedback (preferably in the linked bug)

Karl (rexcramer66) said : #2

We have installed that 1.1.2 version today
Unfortunately it didn't help. Starting the IDE (with option -m) still creates that s_i_k_u_l_i-ide-isrunning file in /tmp that blocks any additional IDE start on the same environment from remote clients

I noticed the IDE info says build is 2017-03-29 and version is 1.1.1, while installer name says its 2017-10-17 and version 1.1.2 ?

Could we perhaps work around the global lock file by using local environment variable ?

RaiMan (raimund-hocke) said : #3

Sorry, but then you are doing anything wrong,

- run the setup jar from the nightly build page 1.1.2 preferably in an empty folder
- use the created sikulix.jar to start the IDE, e.g. from a command line as java -jar sikulix.jar -m

This should open an IDE with the build stamp of 2017-10-17.

... and then you can start another IDE the same way.

I guess you have to revise your setup, to assure the created sikulix.jar 1.1.2 is used.

Karl (rexcramer66) said : #4

Ok, found out what was wrong
Since the environment we are using Sikulix on is not connected to internet, we had to go with then offline installation procedure - and were using the libs that are available on the "offline installation" description page. These libs are all 1.1.1

The workaround now was to install Sikulix to an internet-connected standalone machine, and afterwards copy the downloaded 1.1.2 lib files to the other environment.

Up to now looks like the -m switch works great :)
Much thanks for the help

RaiMan (raimund-hocke) said : #5

Thanks for feedback. All the best.