Schrift
Wiki:Tipp zum Debugging: use Data::Dumper; local $Data::Dumper::Useqq = 1; print Dumper \@var;
[thread]11008[/thread]

Lock - Verarbeitung gesperrt



<< |< 1 2 >| >> 13 Einträge, 2 Seiten
jons
 2007-12-12 13:35
#103767 #103767
User since
2007-12-12
7 Artikel
BenutzerIn
[default_avatar]
Hallo, ich(Perl/CGI-Laie) bitte um Unterstützung.

Es geht um ein Perl-Programm, bzw. zwei (Kleinanzeigenmarkt + Kalendertool, beides Freewareprg. der Fa. Active Web Suite aus dem Jahr 2000). Die Programme laufen auf Webspace von Strato. Lt. Protokoll sind die Prg. seit 2002 im Einsatz. Der Support von Strato konnte oder wollte mir nicht weiterhelfen, da es keine strato-cgi-scripte sind.

Seit Ende Sept. 2007 gibt es aber Probleme mit den zwei Programmen.

Lt. Fehlerprotokoll kommt immer zu "LOCK, Standard Timeout".

So wie ich es als perl/cgi-Laie festgestellt habe, kann ich einen Verarbeitungschritt (z. B.: eine Kleinanzeige löschen, Datenbank sichern, etc.) erledigen, danach kommt der "Standard Timeout", es wird ein Verzeichnis LOCK angelegt, beim nächsten Verarbeitungsschritt kommt auf dem Monitor die Fehlermeldung LOCK. Lösche ich das Verzeichnis LOCK, dann kann ich wieder einen Verarbeitungsschritt machen. Aber immer nur einen.
Meines Erachtens
Warum wird die Verarbeitung aber gesperrt?
Der Fehler ist wirklich erst seit Ende Sept. da, jahrelang vorher nicht. Warum? An den Quellcodedateien ist keine Veränderung erfolgt.

Im Forum von perlunity.de habe ich diese Fragen schon gestellt aber keine Antwort erhalten.
Vielen Dank im voraus für jede Antwort.

MfG
jons


Nachforschungen zu LOCK, Standard Timeout haben mich zu einer Datei routines.pl geführt, wo mir die u. a. Routine/Sub aufgefallen ist:

Code: (dl )
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
sub exclusive_lockfile {

# check to see if we got an exclusive lock on the file
# and if not, sleep 1 second and try again until we have
# tried for a total of 20 seconds. If we could not get
# an exclusive lock within 20 seconds, let's exit with an
# error message.

my ($file_handle) = @_;
$lock_file = "$file_handle.lock";
$sleep_count = 0;
$request = "$as{'request'}";

if (-M "$require_path/$file_handle/$lock_file" > .001) {
unlink("$require_path/$file_handle/$lock_file");
rmdir("$require_path/$file_handle");
&log_flock($file_handle, "Forced Unlock Performed", $request);
}

# perform a check for a lock that may have gotten left behind
# because an error occurred previously.

while ($sleep_count < 20) {

if (!-e "$require_path/$file_handle") {
mkdir("$require_path/$file_handle", 0777);
chmod(0777, "$require_path/$file_handle");
open(LOCK_FILE, ">$require_path/$file_handle/$lock_file");
flock(LOCK_FILE, 2) if ($flock == 1);
last;
} else {
$sleep_count++;

if ($sleep_count > 19) {
&log_flock($file_handle, "Standard Timeout", $request);
&error_cannot_lock;
}
sleep(1);
next;
}
} # end of while

} # end of sub


Meine Vermutung ist, das die Routine für die Fehlermeldung, das Sperren verantwortlich ist.

So, um den Fehler vielleicht besser zu erkennen, habe ich in der Zwischenzeit die zwei Sripte bei einem anderem Webhoster installiert und getestet. Dort habe ich keine Probleme in der Datenverarbeitung. Im Fehlerprotokoll wird auch
nichts vermerkt.

Warum aber beim Webhoster Strato?
Struppi
 2007-12-16 13:40
#103926 #103926
User since
2006-02-17
628 Artikel
BenutzerIn
[Homepage]
user image
jons+2007-12-15 15:09:35--
so wie ich es gelesen habe, macht dieser Lockmechanismus schon Sinn um betreffende Datendateien vor einer Schädigung zu schützen.
Schon klar, aber dafür existiert die Funktion http://perldoc.perl.org/functions/flock.html, das ganze drumherum ist eigentlich nicht nötig.
jons
 2007-12-15 13:01
#103937 #103937
User since
2007-12-12
7 Artikel
BenutzerIn
[default_avatar]
Hallo,

hat keiner einen Tipp?

Könnte es an den Programmen, den Daten oder der Serverkonfiguration liegen?

Habe ich meine Fragen zu ungenau gestellt?

Für jede Mithilfe danke ich vielmals.

Gruss
jons
Struppi
 2007-12-15 14:09
#103941 #103941
User since
2006-02-17
628 Artikel
BenutzerIn
[Homepage]
user image
Ich weiß nicht ob dieser Lockmechanismus ein guter ist, ich hatte aber auch schon Probleme mit flock, bin aber dem nicht mehr nachgegangen.

Da offensichtlich das Lockfile nicht gelöscht wird, läuft da irgendwas falsch, die einzige Möglichkeit rauszufinden was, ist es die Rückgabewerte der beteiligten Funktionen zu prüfen, damit du weißt wo etwas falsch läuft.

z.b.
Code (perl): (dl )
unlink("$require_path/$file_handle/$lock_file") or die "Löschen von ($require_path/$file_handle/$lock_file) schlug fehl: $!";
jons
 2007-12-15 16:09
#103943 #103943
User since
2007-12-12
7 Artikel
BenutzerIn
[default_avatar]
Hallo,
so wie ich es gelesen habe, macht dieser Lockmechanismus schon Sinn um betreffende Datendateien vor einer Schädigung zu schützen.

Manchmal klappt es ja wohl auch wie gewollt. Aber warum nur manchmal?

Gerade habe ich es nochmal getestet: Den Admin-Bereich aufgerufen und ein Datenbankbackup ausgewählt. Erfolgreich. Dann ein Backup der Systemdateien ausgewählt. Kein Erfolg: Meldung LOCK.

Das leere Verzeichnis LOCK dann per Hand gelöscht und schon war der Aufruf über das Admin-Menue erfolgreich.

Gruss
jons
jons
 2007-12-23 12:58
#104111 #104111
User since
2007-12-12
7 Artikel
BenutzerIn
[default_avatar]
Hallo,

ich melde mich jetzt erst wieder, da ich erst einmal ein wenig Abstand von flock, Lockmechanismus, Routinen usw. bekommen musste. Je mehr ich mich damit beschäftigte umso komplizierter wurde das Ganze.

Kern des Problems ist:
Warum läuft jahrelang alles rund, ab einem bestimmten Zeitpunkt gibt es Verarbeitungsprobleme.

Was ist der Auslöser des Verarbeitungsproblems?

Vorerst verbleibe ich mit besten Weihnachtswünschen
jons



Struppi
 2007-12-23 15:22
#104116 #104116
User since
2006-02-17
628 Artikel
BenutzerIn
[Homepage]
user image
Der Auslöser ist vermutlich ein Fehler beim erzeugen und/oder löschen der Lockfiles, hab ich doch schon geschrieben. Nur dazu müßte man Wissen ob und welcher Fehlermeldung die Funktion ausgibt, da das Skript diese aber ignoriert müßte man hellsehen können um die Ursache zu finden.
jons
 2007-12-23 15:53
#104117 #104117
User since
2007-12-12
7 Artikel
BenutzerIn
[default_avatar]
Hallo Struppi,

vielleicht hilft es weiter. Ich habe hier einen kleinen Auszug aus der Fehlerdatei:
Code: (dl )
1
2
3
4
Sun Dec 23 11:42:48 2007|submit_new_ad_details|LOCK|Standard Timeout
Sun Dec 23 11:45:45 2007|ad_maintenance|LOCK|Standard Timeout
Sun Dec 23 11:45:54 2007|ad_maintenance|LOCK|Standard Timeout
Sun Dec 23 11:49:12 2007|submit_new_ad_details|LOCK|Standard Timeout

MfG
jons
Struppi
 2007-12-24 12:36
#104138 #104138
User since
2006-02-17
628 Artikel
BenutzerIn
[Homepage]
user image
nein, das hilft nicht, diese Meldung sind ja die Konsequenz aus den Fehlern die zuvor auftreten, die dein skript aber ignoriert.
Zum lösen deines Problemes bräuchtest du die Fehlermeldungen von deiner unlock Routine.
jons
 2007-12-28 13:48
#104202 #104202
User since
2007-12-12
7 Artikel
BenutzerIn
[default_avatar]
Hallo,

so jetzt habe ich eine andere vom System erzeugte Fehlermeldung:

The following error has occured in your script.
Undefined subroutine &main::error_cannot_lock called at library/routines.pl line 1177.


Ich habe kurz nachgeschaut, in der routines.pl in der Zeile 1177 steht:
if ($sleep_count > 19) {

Der Rest der Routine/Funktion steht in meinen Beitrag 1.

Hilft diese Fehlermeldung vielleicht weiter?

MfG
jons
<< |< 1 2 >| >> 13 Einträge, 2 Seiten



View all threads created 2007-12-12 13:35.