<div dir="ltr"><div><div><div>good anwers Tobi, but also too complicated:<br><br>ps -lxa | grep " & nameproc & " | sed 's/Â Â */ /g' | cut -d' ' -f3,13,14,15<br><br></div>nameproc must have the first char close inside "[" "]" and that's all<br><br></div>NOW THE PROBLEM I[TS THAT THE WIKI OFFILE IF A PAGE ARE NOT IN MY LANG DOES NOT DISPLAY ANYTHIG!<br><br></div>the offline wiki are only usefully in english!<br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><font color="#888888">Lenz McKAY Gerardo (PICCORO)</font><div><font color="#888888"><a href="http://qgqlochekone.blogspot.com" target="_blank">http://qgqlochekone.blogspot.com</a></font></div></div></div>
<br><div class="gmail_quote">2018-05-31 12:13 GMT-04:00 Tobias Boege <span dir="ltr"><<a href="mailto:taboege@gmail.com" target="_blank">taboege@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, 31 May 2018, Rolf-Werner Eilert wrote:<br>
> Piccoro, you are right, a complete solution would then<br>
> <br>
> - check for dbus, and if it isn't there:<br>
> - check for pgrep, and if it isn't there:<br>
> - use a lock file<br>
> <br>
<br>
</span>I don't know anything about dbus. In that case I shouldn't say this, but:<br>
it looks like overhead for this task, even if it's just conceptual overhead.<br>
I'm elaborating on the latter two fallbacks a bit here.<br>
<br>
pgrep not being installed isn't a huge problem. If you wanted, you<br>
could rewrite it in a few lines of Gambas -- if you assume your target<br>
is a Linux system. My problem with pgrep is that you have to essentially<br>
hard-code the name of your program into its code. Using Application.Name<br>
is slightly better from a maintenance point of view, but still prevents<br>
the user from renaming your .gambas executable or executing it using<br>
alternate names or symlinks. If you want to go into /proc/<PID>/cmdline,<br>
to find out what Gambas project really runs, you'll quickly find yourself<br>
resolving symlinks and comparing checksums, for instance, and what about<br>
two different versions of your project which exist on the same machine?<br>
It just isn't a robust solution in the face of things that a user could<br>
realistically want to do.<br>
<br>
I like a lock file much more. Not only is it available on any POSIX<br>
system, but you don't actually have to worry about application crashes<br>
(not even the ones Application_Error can't save you from). Gambas'<br>
LOCK and UNLOCK instructions use the lockf() interface, which provides<br>
an exclusive lock managed by the kernel. If your process dies, the lock<br>
will be automatically released from higher up, without you doing anything.<br>
<br>
Play around with the attached project, start it as two processes A and B<br>
and in particular convince yourself that:<br>
<br>
 * if A is running and has the lock, B will fail to acquire the lock<br>
  after trying for 2 seconds,<br>
 * if A terminates, it will release the lock and if B is started<br>
  afterwards, it will succeed acquiring the lock,<br>
 * if A is running and has the lock, start B and within 2 seconds<br>
  hit Ctrl+C in the terminal running A. The installed signal handler<br>
  will make process A crash hard with a segfault (which is not<br>
  recoverable via Application_Error). Gambas has no chance to release<br>
  the lock itself, but instead the kernel releases the lock while<br>
  tidying up process A, and B succeeds to acquire the lock as soon<br>
  as that has happened!<br>
<br>
I would advise that you read the manpage for lockf() though. It mentions<br>
that the lock is released as soon as *any* file descriptor of a process<br>
holding the lock is closed. This means that you *could* lock the file<br>
twice (this is allowed by lockf) and lose your lock when the first stream<br>
object representing your lock in Gambas goes out of scope -- even though<br>
your process is still running. I don't think that will usually happen,<br>
but still good to know. Also note that locks aren't inherited by child<br>
processes, e.g. when you Shell, Exec or Task. Sadly, LOCK and UNLOCK<br>
relying on lockf() are an implementation detail, so this kind of stuff<br>
is missing from the documentation.<br>
<br>
Finally, some standalone daemons like fetchmail use a combined approach:<br>
when the daemon is starting, it writes its PID into a special file like<br>
$HOME/.fetchmail.pid, possibly also putting a lock on that file.<br>
Writing the PID directly into a predetermined file avoids all the<br>
complications of using pgrep. Furthermore, a new instance of your program<br>
can read the PID file, determine if the process is still alive by probing<br>
the lock and then send commands or a "wake up" signal to the daemon.<br>
For example, if I run `fetchmail` and it detects that fetchmail already<br>
runs in daemon mode (by examining $HOME/.fetchmail.pid), the newer<br>
fetchmail will not just terminate, it will tell the fetchmail daemon<br>
that I want it to fetch my mail *now* and not on the next regular cycle.<br>
<br>
You can also use that as a limited crash detection. If you write your<br>
application so that it removes the lock file upon normal exit, and you<br>
at some point detect that the lock file exists without being locked,<br>
your program has likely crashed. Vim, for example, informs you about<br>
this kind of stuff and offers to attempt to recover files, abort starting<br>
or tidy up for you.<br>
<br>
My point is: if you don't need fancy DBUS-IPC capabilities, reconsider<br>
if a lock file should really be the last fallback on your list, and<br>
not the default implementation.<br>
<br>
Regards,<br>
Tobi<br>
<span class="HOEnZb"><font color="#888888"><br>
-- <br>
"There's an old saying: Don't change anything... ever!" -- Mr. Monk<br>
</font></span><br><br>
----[ Gambas mailing-list is hosted by <a href="https://www.hostsharing.net" rel="noreferrer" target="_blank">https://www.hostsharing.net</a> ]----<br>
<br></blockquote></div><br></div>