Uutiset:

Bored?  Looking to kill some time?  Want to chat with other SMF users?  Join us in IRC chat or Discord

Main Menu
Advertisement:

Leere Seite nach ändern eines Beitrages mit Anhang

Aloittaja beeeee, marraskuu 19, 2007, 03:13:23 IP

« edellinen - seuraava »

beeeee

Hi!

LainaaVersionsinformation:
Forum-Version: SMF 1.1.4 (ausführlicher)
Aktuelle SMF-Version: SMF 1.1.4
PHP-Version: 5.1.2
MySQL-Version: 5.0.18
Server-Version: Apache/2.2.0 (Linux/SUSE)
GD-Version: bundled (2.0.28 compatible)

SMF läuft auf einem V-Server von Strato

Folgendes Problem tritt auf: Ändert ein Mitglied oder ein Admin einen Beitrag, an den ein Anhang angefügt wurde, wird nach anklicken des Speichern-Buttons eine leere Seite angezeigt.  Die URL der aufgerufenen leeren Seite lautet:

Lainaahttp://www.meineseite.de/index.php?action=post2;start=0;msg=151510;sesc=3e614f6cfc36f179685a7912937c3c96;board=72 [nofollow]

Die Rechte des attachment-Ordner sind meines Erachtens richtig gesetzt, das Hochladen klappt auch einwandfrei. Hat jemand eine Idee?

beeeee

#1
Ich habe das produktive System nun auf einem Windows-XAMPP installiert, dort klappt das einwandfrei. Mir ist allerdings aufgefallen, dass SMF die Attachments mit dem Owner "wwwrun" und den Rechten "644" ablegt. Ist das normal? Aber auch wenn ich die Dateirechte des Anhangs auf "777" und auf den "normalen" Owner umstelle bringt das nichts...

Wenn ich das error.log aktiviere wird mir diese Fehlermeldung ausgegeben;

Datenbankfehler: Lost connection to MySQL server during query
Datei: /srv/www/vhosts/meineseite.de/httpdocs/Sources/Post.php
Zeile: 1428


An besagter Stelle in post.php steht dies:

// If this isn't a new post, check the current attachments.
if (isset($_REQUEST['msg']))
{
$request = db_query("
SELECT COUNT(*), SUM(size)
FROM {$db_prefix}attachments
WHERE ID_MSG = " . (int) $_REQUEST['msg'] . "
AND attachmentType = 0", __FILE__, __LINE__);
list ($quantity, $total_size) = mysql_fetch_row($request);
mysql_free_result($request);
}

dieter4

Der MySQL-Server scheint etwas schwach auf der Brust zu sein. Der haut einfach während des Änderns ab ;)

Wenn du einen bezahlten Webspace hast würde ich das mal dem Hoster melden.

beeeee

Ich habe einen V-Server bei Strato gemietet. Mit mySQL hatte ich eigentlich keine Probleme bisher. Wenn ich genau dieses SQL-Statement direkt über die Konsole ausführe klappt das, da gibt's ja auch nicht viel zu zählen.

Sonst laufen alle sonstigen SQL-Abfragen einwandfrei, nur diese eine nicht...


dieter4

Wie lang hast du die maximale Verbindungszeit eingestellt? Ich weiß jetzt net auswendig, wie die entspr. Funktion heißt.

beeeee


dieter4


beeeee

Die Variable wait_timeout in mySQL steht auf 28800, also 8 Stunden.

Dies hier hilft leider auch nicht weiter: http://dev.mysql.com/doc/refman/5.0/en/gone-away.html [nofollow]

Da sich die Abfrage problemlos auf Konsolenebene oder in phpMyAdmin ausführen lässt würde ich einen Fehler in mySQL ausschließen. smf_attachments hat lediglich 700 Zeilen, der Query in der Konsole braucht 0,00004 Sekunden oder so.

In SMF habe ich bei den Servereinstellungen schon mit der dauerhaften DB-Anbindung experimentiert, bringt leider auch nichts.

Weiterhin habe ich ein komplett frisches SMF 1.1.4 in einen Unterordner und eine eigene Datenbank installiert. Klappt einwandfrei. Dann habe ich die produktive Datenbank mittels mysqldump abgezogen und in die frische Installation eingespielt. Nun tritt das Problem wieder auf. Wie gesagt, es sind lediglich 700 Anhänge die durchsucht werden müssen, das sollte doch nicht das Problem sein.

Das installierte SMF läuft mit 130.000 Posts richtig schnell, die performante Suchfunktion arbeitet einwandfrei. Nur eben diese kleine Abfrage nicht.

Ich bin ratlos... :'(

@Neakro: Vielen Dank für deine bisherige Unterstützung!

dieter4

Leider muss ich gestehen, dass ich im Moment auch ratlos bin. :(

Es kommt aber häufiger vor, dass bei großen Abfragen der MySQL sich verabschiedet. Nur ist dies keine große Abfrage.

beeeee

So wie es aussieht ist mein V-Server falsch konfiguriert, er verbraucht zu viel Speicher, dann wird die mySQL-Datenbank abgeschossen. Nur komisch, dass das ausgerechnet nur bei dieser Abfrage ist...

Egal, vielen Dank für deine Hilfe Neakro.

Advertisement: