Preventing duplicate images to run

Hi all,

Is thre some code already there to prevent another image with the same
name to accidentally be started?

I namely have an icon to start my image on Linux but administrators used
to Windows are double clicking on that icon, which on Linux of course
starts two instances of the same image.

Question is therefore how to avoid starting the second instance of the
same image in such a case?

Thanks in advance for any hint.

Best regards
Janko


--
Janko Mivšek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

On Mon, 14 Jun 2010 21:35:31 +0200, Janko Mivšek <[hidden email]>
wrote:
> Hi all,
>
> Is there some code already there to prevent another image with the same
> name to accidentally be started?
>
> I namely have an icon to start my image on Linux but administrators used
> to Windows are double clicking on that icon, which on Linux of course
> starts two instances of the same image.

Janko.. Not sure if there's anything in VW to prevent this but
since you're on Unix, why not have a shell script connected to the
icon instead of VW directly.. That way the shell script can do
some extra checking to ensure only one image is running and the 2nd
can just do an 'exit' to terminate the script early..  There are
probably other.. ummm.. more elegant solutions but this could be
used in a last ditch effort if nothing else pans out.
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Thanks Rick for your idea. Problem is how to write such a script. Maybe
such script already exist for some other Linux software?

Best regards
Janko

On 14. 06. 2010 22:21, Rick Flower wrote:
> On Mon, 14 Jun 2010 21:35:31 +0200, Janko Mivšek <[hidden email]>
> wrote:

--
Janko Mivšek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Hi Joachim,

Thanks a lot for your hint. I looked a bit at your link about Linux
semaphores, but I'm afraid to be to a bit short in Linux programming to
go this way.

What about a technique with a simple lock file <image-name>.lck,
wouldn't be a simple enough solution for that? And nicely portable
between Win and linux.

Procedure would something like that:

1. image at startup checks if that lock file exists
2. if no, it creates it and continue with startup procedure
3. if yes, it writes a warning in the Transcript, waits for few seconds,
then shutdown.

Of course there are many "what ifs" to be considered, like what if image
crashed and lock file stays there from before, etc. but in general I
have a feeling this could be the simplest solution.

Janko

On 15. 06. 2010 08:05, Joachim Geidel wrote:
--
Janko Mivšek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Have the image acquire a socket on a specific port, who owns the socket is allowed to run.

HTH,

Martin

"Janko Mivšek"<[hidden email]> wrote:
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Or get a write lock on a specific file. Deleting the file on exit is then also a way to tell if your program is running or has crashed.

Steve

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email]
Sent: Tuesday, June 15, 2010 4:36 PM
To: Janko Mivšek
Cc: 'VWNC'
Subject: Re: [vwnc] Preventing duplicate images to run

Have the image acquire a socket on a specific port, who owns the socket is allowed to run.

HTH,

Martin

"Janko Mivšek"<[hidden email]> wrote:
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Firefox is an example of the lock file approach that Janko mentioned. Google "parent.lock" to learn how they use it and the issues involved.

Years ago I'd used a variation of that approach...

If the locking session terminates without cleanup then the file will exist and appear locked. You could write something like a PID to the lock file to provide some means of automatic recovery from stale locks. You can query the OS and see that that PID from the lock file is no longer being used (not exact, I know). The application can be expected to refresh the lock file every so often. If pid is dead or the timestamp of the lock file is out of range then treat it as a stale lock. If there is a chance that the lock-holding session was temporarily delayed then you could have a lock-holding session verify that it is still the pid found in the lock file. Deleting or changing the lock file then becomes a polite way to ask the locking session to shut itself down on the next check interval.

If you are using GemStone then these issues are easy to handle, you just acquire a lock on an object representing the task you want to synchronize. GS/S (normally) releases the locks automatically if the gem dies.

Paul Baumann


-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Janko Mivšek
Sent: Tuesday, June 15, 2010 9:05 AM
To: 'VWNC'
Subject: Re: [vwnc] Preventing duplicate images to run

Hi Joachim,

Thanks a lot for your hint. I looked a bit at your link about Linux semaphores, but I'm afraid to be to a bit short in Linux programming to go this way.

What about a technique with a simple lock file <image-name>.lck, wouldn't be a simple enough solution for that? And nicely portable between Win and linux.

Procedure would something like that:

1. image at startup checks if that lock file exists 2. if no, it creates it and continue with startup procedure 3. if yes, it writes a warning in the Transcript, waits for few seconds, then shutdown.

Of course there are many "what ifs" to be considered, like what if image crashed and lock file stays there from before, etc. but in general I have a feeling this could be the simplest solution.

Janko

On 15. 06. 2010 08:05, Joachim Geidel wrote:
--
Janko Mivšek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

This message may contain confidential information and is intended for specific recipients unless explicitly noted otherwise. If you have reason to believe you are not an intended recipient of this message, please delete it and notify the sender. This message may not represent the opinion of IntercontinentalExchange, Inc. (ICE), its subsidiaries or affiliates, and does not constitute a contract or guarantee. Unencrypted electronic mail is not secure and the recipient of this message is expected to provide safeguards from viruses and pursue alternate means of communication where privacy or a binding message is desired.


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

utilizing #lock:for: might help.

although it won't work (no lock) with certain kind of mounted volumes
(NFS etc.)

sometimes it would be helpful if VW would allow to create non-shared
streams.

-----

acquireLock

   ^ [
     lockStream := self lockFilename writeStream text.
     [
       lockStream ioConnection output lock: true for: 1.
       lockStream nextPutAll: 'Locked by process '.
       OSHandle currentProcessID printOn: lockStream
     ] ifCurtailed: [ lockStream close ].
     " got the lock "
     lockStream
   ] on: OsError do: [ : ex |
     self error: 'Could not get the lock'.
     nil
   ].

releaseLock

   lockStream  notNil
     ifTrue: [ lockStream close ].


--
Holger Kleinsorgen | Senior Software Engineer
intelligent views gmbh
Julius-Reiber-Str. 17 | 64293 Darmstadt

Tel/Fax ++49 (0)6151 5006-241 | Fax ++49 (0)6151 5006-138
e-mail: [hidden email] | http://www.i-views.de

Geschäftsführer: Achim Gärtner, Jörg Kleinz, Klaus Reichenberger
Die Gesellschaft ist eingetragen beim Amtsgericht Darmstadt
(Sitz der Gesellschaft) Nr. HRB 7965
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

[hidden email] wrote:
> Have the image acquire a socket on a specific port, who owns the socket is allowed to run.
>  
This works *very well* in the small.
However when this gets deployed at customers you will find you need
cooperation from the OS in having reserved that port for your app.

Some problems I'm aware of
1) you use a low-numberd port and find that your customer does not have
permissins to bind that port as a listener.

2) you use a high numbered port number (aka 'ephemeral' port number) and
run into the situation where an other app has already (ephemerally)
bound it - hard to reproduce but rather nasty when it happens.

3) between application crash and relaunch the port number remains
reserved by the system for a while (say .5 min ... 5 min) - this can be
mitigated somewhat by using the SO_REUSEADDR flag but its semantics
differ widely among OSen and might even break our intended usage of
sockets here.


The nice thing of a socket is that you can use it to communicate with
'the' already running instance, like having it make its windows come to
the foreground when the user tries to launch a second instance.

R
-

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

What about the file lock suggestion then?

-Boris (via BlackBerry)

----- Original Message -----
From: [hidden email] <[hidden email]>
To: 'VWNC' <[hidden email]>
Sent: Thu Jun 17 07:43:58 2010
Subject: Re: [vwnc] Preventing duplicate images to run

[hidden email] wrote:
> Have the image acquire a socket on a specific port, who owns the socket is allowed to run.
>  
This works *very well* in the small.
However when this gets deployed at customers you will find you need
cooperation from the OS in having reserved that port for your app.

Some problems I'm aware of
1) you use a low-numberd port and find that your customer does not have
permissins to bind that port as a listener.

2) you use a high numbered port number (aka 'ephemeral' port number) and
run into the situation where an other app has already (ephemerally)
bound it - hard to reproduce but rather nasty when it happens.

3) between application crash and relaunch the port number remains
reserved by the system for a while (say .5 min ... 5 min) - this can be
mitigated somewhat by using the SO_REUSEADDR flag but its semantics
differ widely among OSen and might even break our intended usage of
sockets here.


The nice thing of a socket is that you can use it to communicate with
'the' already running instance, like having it make its windows come to
the foreground when the user tries to launch a second instance.

R
-

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Hi all,

I'm just finishing the ImageLocker package/parcel, which will be soon
available on the public Store.

I went the lock file way as proposed by Paul and with locking proposed
by Holger. I considered the Socket idea by Martin as well but had the
same doubts as Reinout pointed out.

So far so good, just the last thing: when to run ImageLocker
checkAnddLock and how to register this method to be called just after
the GUI is functional and code evaluation already works, but no other
user defined systems are not yet started?

Best regards
Janko

On 17. 06. 2010 16:46, Boris Popov, DeepCove Labs (YVR) wrote:
--
Janko Mivšek
AIDA/Web
Smalltalk Web Application Server
http://www.aidaweb.si
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc