[Gambas-user] donot permit another instance of my program

[PICCORO McKAY Lenz]

good anwers Tobi, but also too complicated:

ps -lxa | grep " & nameproc & " | sed 's/   */ /g' | cut -d' ' -f3,13,14,15

nameproc must have the first char close inside "[" "]" and that's all

NOW THE PROBLEM I[TS THAT THE WIKI OFFILE IF A PAGE ARE NOT IN MY LANG DOES
NOT DISPLAY ANYTHIG!

the offline wiki are only usefully in english!

Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

2018-05-31 12:13 GMT-04:00 Tobias Boege <taboege at gmail.com>:

> On Thu, 31 May 2018, Rolf-Werner Eilert wrote:
> > Piccoro, you are right, a complete solution would then
> >
> > - check for dbus, and if it isn't there:
> > - check for pgrep, and if it isn't there:
> > - use a lock file
> >
>
> I don't know anything about dbus. In that case I shouldn't say this, but:
> it looks like overhead for this task, even if it's just conceptual
> overhead.
> I'm elaborating on the latter two fallbacks a bit here.
>
> pgrep not being installed isn't a huge problem. If you wanted, you
> could rewrite it in a few lines of Gambas -- if you assume your target
> is a Linux system. My problem with pgrep is that you have to essentially
> hard-code the name of your program into its code. Using Application.Name
> is slightly better from a maintenance point of view, but still prevents
> the user from renaming your .gambas executable or executing it using
> alternate names or symlinks. If you want to go into /proc/<PID>/cmdline,
> to find out what Gambas project really runs, you'll quickly find yourself
> resolving symlinks and comparing checksums, for instance, and what about
> two different versions of your project which exist on the same machine?
> It just isn't a robust solution in the face of things that a user could
> realistically want to do.
>
> I like a lock file much more. Not only is it available on any POSIX
> system, but you don't actually have to worry about application crashes
> (not even the ones Application_Error can't save you from). Gambas'
> LOCK and UNLOCK instructions use the lockf() interface, which provides
> an exclusive lock managed by the kernel. If your process dies, the lock
> will be automatically released from higher up, without you doing anything.
>
> Play around with the attached project, start it as two processes A and B
> and in particular convince yourself that:
>
>   * if A is running and has the lock, B will fail to acquire the lock
>     after trying for 2 seconds,
>   * if A terminates, it will release the lock and if B is started
>     afterwards, it will succeed acquiring the lock,
>   * if A is running and has the lock, start B and within 2 seconds
>     hit Ctrl+C in the terminal running A. The installed signal handler
>     will make process A crash hard with a segfault (which is not
>     recoverable via Application_Error). Gambas has no chance to release
>     the lock itself, but instead the kernel releases the lock while
>     tidying up process A, and B succeeds to acquire the lock as soon
>     as that has happened!
>
> I would advise that you read the manpage for lockf() though. It mentions
> that the lock is released as soon as *any* file descriptor of a process
> holding the lock is closed. This means that you *could* lock the file
> twice (this is allowed by lockf) and lose your lock when the first stream
> object representing your lock in Gambas goes out of scope -- even though
> your process is still running. I don't think that will usually happen,
> but still good to know. Also note that locks aren't inherited by child
> processes, e.g. when you Shell, Exec or Task. Sadly, LOCK and UNLOCK
> relying on lockf() are an implementation detail, so this kind of stuff
> is missing from the documentation.
>
> Finally, some standalone daemons like fetchmail use a combined approach:
> when the daemon is starting, it writes its PID into a special file like
> $HOME/.fetchmail.pid, possibly also putting a lock on that file.
> Writing the PID directly into a predetermined file avoids all the
> complications of using pgrep. Furthermore, a new instance of your program
> can read the PID file, determine if the process is still alive by probing
> the lock and then send commands or a "wake up" signal to the daemon.
> For example, if I run `fetchmail` and it detects that fetchmail already
> runs in daemon mode (by examining $HOME/.fetchmail.pid), the newer
> fetchmail will not just terminate, it will tell the fetchmail daemon
> that I want it to fetch my mail *now* and not on the next regular cycle.
>
> You can also use that as a limited crash detection. If you write your
> application so that it removes the lock file upon normal exit, and you
> at some point detect that the lock file exists without being locked,
> your program has likely crashed. Vim, for example, informs you about
> this kind of stuff and offers to attempt to recover files, abort starting
> or tidy up for you.
>
> My point is: if you don't need fancy DBUS-IPC capabilities, reconsider
> if a lock file should really be the last fallback on your list, and
> not the default implementation.
>
> Regards,
> Tobi
>
> --
> "There's an old saying: Don't change anything... ever!" -- Mr. Monk
>
>
> ----[ Gambas mailing-list is hosted by https://www.hostsharing.net ]----
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gambas-basic.org/pipermail/user/attachments/20180531/a4bc2f08/attachment.html>