stale lock removal in run_notify.php

[GoogleCodeExporter]

I had a database crash (due to an out of memory event). 
When this happened, it is likely that a run_notify job was running, because 
after I fixed it, run_notify refuses to run assuming there is another running 
instance. 

// Check if another instance of the script is running
$lock_file = fopen("/tmp/notification-run_notify.lock", "w");
if (!flock($lock_file, LOCK_EX | LOCK_NB)) { // Another instance of the script 
is running - exit
    echo "Another instance of run_notify.php is currently running.\nExiting.\n";
    fclose($lock_file);
    exit;
}
// No other instance - do normal processing

How can a stale lock be detected and resolved without manual intervention from 
the sysadmin? 

Original issue reported on code.google.com by andrixnet on 27 Nov 2014 at 8:02

• Blocked on: #79

[GoogleCodeExporter]

This is an open lock on a file, not the presence of a .lock file method. 
However, my webserver is doing a graceful restart every 15 minutes to work 
around issue 79. 
Should it do a hard restart?

Original comment by andrixnet on 27 Nov 2014 at 8:13

• Added labels: Type-Other
• Removed labels: Type-Defect

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

WHen server crash, lock stays i think, and you need to remove it manualy.
BTW server should not crash every 15 minutes for any reason. Your machine seems 
to not be in very good health condition.

I think you need find someone who can configure your machine properly and 
according to opencaching code requirments.
(You even do not use MySQL database, this is basic requirement, we cannot solve 
problems caused database incompatibility - and your crash problem can be caused 
database incompatibility
And if I was you, I wiould start from instaling MySQL database).

Original comment by wloczynutka on 28 Nov 2014 at 8:01

[GoogleCodeExporter]

Original comment by andrixnet on 28 Nov 2014 at 8:48

• Now blocked on: #79

[GoogleCodeExporter]

From the analzsis I performed later, I could only determine that there must 
have been a memory leak of some kind, because most system memory, including 
virtual memory was completely full with httpd process occupying 60% of total. 
I chose to do a full reboot to get a clean start. After that it worked again. 

Please note the following: 
- I am using the __same__ system configuration and software versions (tuned for 
lower memory) that I use for several heavyduty webservers at work hosting 
multiple websites on several different platforms, including PHP, PERL, PYTHON 
with several well known site kits and also custom written web applications. 
- There is a known issue with MariaDB (only because it's behaviour is properly 
implemented while MySQL's implementation isn't, see issue 120)
- PHP interpreter changes across versions and I fully agree that there may be 
some small incompatibilities somewhere because of this. 
- Another consideration is applying security patches and this means upgrading 
versions. Using an old, known to be buggy and vulnerable core component is _bad 
practice_. 

--------------------
I will monitor the situation and return with details of my findings. 

Thank you. 

Original comment by andrixnet on 28 Nov 2014 at 12:57

• Changed state: Invalid

[GoogleCodeExporter]

If it was memory leak error in php script most probably you'd get error like 
that: "Allowed memory size of XXXXXX bytes exhausted (tried to allocate Y 
bytes)" It shouldn't cause server failure. (this error just breaks current 
script executing)

I run oc_code on quite up-to-date software: 
Apache/2.4.7, 
PHP Version 5.5.9,
MySQL Community Server (GPL) 5.6.16

no problems, then I can say, opencaching code is compatibile with new software.

Try to find db query which cause crash. you can do it by manual executing one 
by one cron jobs until you get crash, then analyse that script, which cause 
crash.

Original comment by wloczynutka on 30 Nov 2014 at 2:52