Run_once() about mycheckpoint HOT 10 OPEN

Exact version: mycheckpoint rev 208, build 201011041330.

I filed this as a feature request, but the reason for writing the patch was a 
processlist overloaded with mycheckpoints hanging on (local) monitored db not 
being ready.

Thank you, good patch. Will incorporate.

Can you please first elaborate on implied bug, where mycheckpoint hangs on db 
not being ready? In what sense "not being ready"?
I would file this as a separate bug, if possible.

Will need to allow for multiple instances of mycheckpoint if directed at 
different servers.
Can you offer such patch (i.e. locking on a different file other than the 
executable)? Otherwise I'll find a solution, but will take me some time.

Locking on the script itself has as benefit that the lock is released on end of 
(premature) execution.

When locking to an external file, the file needs to exist and one needs the 
remove the lock-file when the program ends. If the program crashed in a 
previous run, one needs to remove the old lock-file at start-up.

In my opinion, if running the program from a central server is the 
default/preferred, the best solution would be to make run-once optional using a 
command line var to turn it on.

But if the default/preferred is to run it from multiple servers to a central db 
(thus logging system i/o etc.), it should be a command line var to switch 
run-once off.

I will have a look into the code (latest rev.) later today, to see if it is 
easy to detect if the script is checking a local or remote db and switch 
run-once off auto if it is checking remote.

"When locking to an external file, the file needs to exist and one needs the 
remove the lock-file when the program ends. If the program crashed in a 
previous run, one needs to remove the old lock-file at start-up."

One could consider using a permanent file for each target host and just use the 
lock attempt on that file. This would require some code to create a filename 
with the name/ip of the target host, if the file doesn't exist.

Will look into that aswell... 

To check whether the script is using remote or local monitoring, compare host 
with monitored_host

[deleted comment]

Here's a patch comparing the ip-address of the monitored host with the 
ip-address of the fqdn of the executing host. This seems te work correctly if 
one is using ip, hostname or fqdn as the monitored_host parameter.

Will submit patch for seperate lock-file per monitored host shortly... 

And here's a patch creating 1 lock file per monitored host (even if it's local, 
keeps code cleaner).

It will create the lock files in /tmp:
-rw-r--r--  1 root  root        0 Sep 21 14:47 mycheckpoint.192.168.23.77.lck


Looking at both patches I'd prefer this one, because code-wise it is 
cleaner/simpler. 
(Still don't like external files/pipes/sockets as means of locking, but in this 
case...)