Run_once()

[GoogleCodeExporter]

What is the feature request?
Run once, to prevent from running more than once from crond.

How will this change current behavior?
Not much, see included patch.

What parameters/options will be required?
None, but one could prefer a "force_run" parameter to bypass run_once

What version of the mycheckpoint are you using?
208

What version of the MySQL are you using?
5.x

On what operating system?
Linux (Gentoo, RH, SuSE)

Original issue reported on code.google.com by mdklapw...@linuxvoid.org on 31 Aug 2011 at 1:06

Attachments:

• mycheckpoint-208.runonce.patch

[GoogleCodeExporter]

Exact version: mycheckpoint rev 208, build 201011041330.

Original comment by mdklapw...@linuxvoid.org on 31 Aug 2011 at 1:36

[GoogleCodeExporter]

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.

Original comment by mdklapw...@linuxvoid.org on 31 Aug 2011 at 1:43

[GoogleCodeExporter]

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.

Original comment by shlomi.n...@gmail.com on 21 Sep 2011 at 8:23

• Changed state: Accepted

[GoogleCodeExporter]

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.

Original comment by shlomi.n...@gmail.com on 21 Sep 2011 at 9:05

[GoogleCodeExporter]

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.

Original comment by mdklapw...@linuxvoid.org on 21 Sep 2011 at 9:29

[GoogleCodeExporter]

"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... 

Original comment by mdklapw...@linuxvoid.org on 21 Sep 2011 at 9:33

[GoogleCodeExporter]

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

Original comment by shlomi.n...@gmail.com on 21 Sep 2011 at 9:34

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

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... 

Original comment by mdklapw...@linuxvoid.org on 21 Sep 2011 at 12:40

Attachments:

• mycheckpoint-208.runonce.local.target.patch

[GoogleCodeExporter]

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...)

Original comment by mdklapw...@linuxvoid.org on 21 Sep 2011 at 1:08

Attachments:

• mycheckpoint-208.runonce.multi.lock.patch