sys_session is marked as crashed and last (automatic?) repair failed

an1world · 11 März 2015, 16:28:23

Hallo Gemeinde!

Ich habe mit meinem PragmaMX ein Problem, welches nicht zu beheben scheint.
Habe schon 1und1 mit diesem Problem konfrontiert, die erkennen nur das Problem am CMS

Fehler:
table './{dbname}/{prefix}_sys_session' is marked as crashed and last (automatic?) repair failed

Ich habe auch schon im Google und hier nach Optionen gesucht und probiert, nur kurze Wirkung
* Tabelle geleert
* Tabelle Repariert
* Tabelle gelöscht und neu eingelesen

Bei 1&1 sieht man eine Möglichkeit wenn es nicht anders geht, einer php.ini Option.
Damit soll die Session nicht in der Datenbank, sondern am Webserver erfolgen.
Nur leider weis ich nicht wie das gehen soll, vor allem, wo der Eintrag und wie geschehen soll.

Ich wäre dankbar für alles an Hilfe und Tipps um das Problem endlich beseitigen zu können.

Mfg
Andreas

waltkemper · 11 März 2015, 19:28:29

Hi, Pragma Version. Link etc.?

Grüße

an1world · 11 März 2015, 19:48:28

Hallo,

es ist die pragmaMx V2.1.2 und die Adresse: www.netzfunk.at
Wobei jetzt auch noch der Error 500 dazu gekommen ist.

Daten:
CMS-Version:
pragmaMx 2.1.2.94 (2014-10-22)
PHP-Version:
5.4.35 (PHP-Info)
MySQL-Version:
5.1.73-1+deb6u1
Server-Version:
Apache

rekord · 11 März 2015, 20:30:55

Hallo,

hatte das gleiche Problem! Das Problem ist ungelöst. Habe die Seite komplett neu aufgesetzt und jetzt läuft sie (noch)

http://www.pragmamx.org/Forum-topic-34506-start-msg214421.html#msg214421

Das eigenartige ist, dass die Seite mit dem berühmten roten Balken seit dem Neuaufsetzen der Seite auf einem anderen Server wieder in Ordnung scheint:

http://www.vda.international-xiphophorus-breeder.net/

gespenstig

an1world · 11 März 2015, 21:01:37

Hallo Rekord,

also ist das wohl ein Problem vom Server selbst, oder einem Script darin?
Mein Problem, es ist schon viel an Daten in der Datenbank eingegangen. (Blogs, Links...)
Wenn ich jetzt alles neu aufsetze, sind die Daten weg und das Hilft wenn der Fehler wieder kommt recht wenig, hmmm

Aber es ist ja nur die sys_session defekt, nicht die ganze DB, oder könnte es auch ein PHP-Script sein was dieses Problem verursacht?

Mfg
Andreas

waltkemper · 12 März 2015, 04:35:27

Hallo, versuche mal per php myadmin oder ähnlichem Programm in deiner Datenbank den Befehl:

SQL Befehl

truncate DEINNAME_sys_session

DEINNAME durch deinen individuellen Eintrag ersetzen! Vorher Datenbank sichern.

Grüße aus Winterscheid

an1world · 12 März 2015, 07:01:09

Hallo Winterscheid,

danke für diesen Tipp, habe es im phpmyadmin und sogar mysqdumper probiert. Hielt nur Kurz an. Keine Ahnung mehr an was das liegen könnte.

MFG
Andreas

Olaf / TerraProject · 12 März 2015, 10:21:41

meine Erfahrung ist, das dieser Fehler auf einen Serverfehler auf dess HD oder Speicher hindeutet. Bitte nochmal den Serveranbieter kontaktieren und auf einen Fehlercheck der HD und des Speichers drängen. Die Tabellen werden ja in Dateien auf der HD des Servers gespeichert.

an1world · 12 März 2015, 11:46:24

hallo,

das es am Server liegt vermute ich auch schon. Ich habe auch schon den Anbieter gefragt ob sie sich dieses Problem anschauen können weils vielleicht am Server oder Speicher liegen könnte. Diese meinten nur, es liege nicht am Server und auch nicht an der Hardware, es wurde alles überprüft. Es wäre ein CMS Problem. So der Provider.

Eigenartig WordPress ist auch am Server funktioniert ohne Probleme. Die bei 1und1 meinten, ich soll die Session auf dem Webspace mittel PHP.INI speichern.

MFG
Andreas

rekord · 12 März 2015, 22:59:13

Hallo,

mein Beitrag war nicht gedacht, eine Lösung auf diese Weise anzubieten, sondern zu bekräftigen, dass es da einen Fehler gibt, der mehrfach auftritt. Ich habe auch darauf aufmerksam gemacht, dass dieses Problem auf einen anderen Server auftrat.Ich hatte mehre Installationen gemacht, bei denen dieser Fehler nach mehr oder weniger langer Zeit wieder auftrat.

an1world · 13 März 2015, 00:04:16

Es ist nur halt eigenartig, dass dieser Fehler zumeist offen bleibt und keine Lösung ansteht. Obwohl dieser ja schon sehr lange bekannt ist. Eventuell hilft ja die PHP.INI Lösung, um genau das zu beheben.

Nur meine Frage:
Wer hat eine Lösung, wie man die sys_session im Webspace anstatt der Datenbank speichern kann. Über die PHP.INI ist das ja angeblich möglich.

DANKE!
Andreas

Twerk · 13 März 2015, 16:55:39

rekord und an1world, nutzt ihr den gleichen Anbieter für euren Server?

an1world · 14 März 2015, 13:56:19

Hallo,

wir haben einen eigenen Manager-Server bei 1und1 laufen, welcher an sich eine gute Leistung hat. 2 Jahre ging es ja auch ohne Probleme.

Lösung oder Versuch??
Da 1und1 der Meinung ist, es sei kein Fehler von 1und1, sondern es lege am CMS selbst. Würde ich gerne einen Versuch mittels eigenen Server (Xampp) starten. Darin dann mein Portal laufen lassen und beobachten, ob selbes Problem austaucht. (Clone meines Servers)

Weil ich denke mir schon, es liegt am Server, wobei komischerweise ja mein Wordpress x2 auf selben Server keine mucken macht. Und wenn doch der Server fehler haben sollte, wäre auch Wordpress betroffen.

Oder was denkt ihr?

Mfg
Andreas

rekord · 15 März 2015, 20:20:39

Hallo,

@Twerk, nein, ich nutze webgo24

Olaf / TerraProject · 16 März 2015, 10:53:30

Da ich immernoch der Meinung bin, daß das ein Serverfehler (HDD) ist, schlage ich folgende Vorgehensweise vor.

1. db sichern.
2. per phpMyAdmin die Tabelle "sys_session" umbenennen in z.Bsp. "sys_session2" (dabei wird phpMyAdmin weiterhin einen Fehler melden - ignorieren)
3. dann per SQL-Befehl im phpMyAdmin folgendes ausführen - (bitte ${prefix} durch deinen Präfix ersetzen..)

Code Auswählen

CREATE TABLE `${prefix}_sys_session` (
  `sesskey` varchar(32) NOT NULL default '',
  `expiry` int(11) unsigned NOT NULL default '0',
  `data` text NULL,
  PRIMARY KEY  (`sesskey`),
  KEY `expiry` (`expiry`)
) ENGINE=MyISAM DEFAULT CHARACTER SET utf8  COLLATE utf8_unicode_ci;

4. dann austesten
5. Rückmeldung hier

an1world · 16 März 2015, 22:57:39

Hallo TerraProject!

DANKE! Das mit dem Script neu einfügen habe ich auch schon, brachte leider nur Kurz etwas. Ich habe daher etwas probiert, was bis jetzt geholfen hat.

NUN ZUM ERFOLG (vorerst)
Der Fehler dürfte nun weg sein, seit Stunden gibt es keine Fehlermeldung mehr

Was habe ich getan? (Tipp!)
1.) Ich habe die Datenbank als GZIP über Phpmyadmin exportiert.
2.) Danach habe ich eine neue Datenbank angelegt.
3.) Die GZIP am Server und dann über MySQLDumper aufgespielt.
4.) Danach im CMS die neue DB eingetragen um Ausfälle zu vermeiden und alte DB gelöscht.

Jetzt sind viele Stunden vergangen und auch Tests, alles dürfte jetzt passen.
An was es genau gelegen hat, weis nicht einmal der Serveranbieter.

Mfg
Andreas

layerf · 18 März 2015, 12:48:15

Ich wollte hier auch mal was dazu beitragen. Dieser Fehler taucht bei uns schon seit einigen Jahren immer mal wieder auf. Hat nicht so viel mit PragmaMX und auch nicht mit dem Provider zu tun.

Dieser Fehler taucht reproduzierbar auf,

1) wenn die Quota(Speicherbegrenzungauf der HD) für den DB-Nutzer ausgeschöpft ist. Dann schreibt der Server irgendwas in die sys_session und zerschießt die Datei.

2) Wenn z.B. durch ein Botnetz-Angriff zuviel Traffic kommt, der Server swapt und auch der Swap-Space ausgeschöpft ist. Dann wird manchmal auch die sys_session zerschossen, da im Speicher Blödsinn steht.

Im Gegensatz dazu, schreibt Wordpress die Sessions nicht in eine Datenbank, ergo passiert das da dann auch nichts.

Fall 1) ist leicht zu lösen Quota erhöhen und eventuell in php.ini den Speicher erhöhen
Fall 2) in robots.txt, .htaccess die bösen Traffiksauger aussperren