Millionen Dateien im tmp Ordner

Hallo Community,

leider haben wir hier in einem kleinen Shop ein merkwürdiges Problem:

Der TMP Ordner von OXID wird über alle Maße zugemüllt, so das er teilweise mehrerer Millionen Dateien enthält. Ist kein Witz! Das Löschen von Hand geht über den FTP Client so gut wie gar nicht mehr. Filezilla hängt sich irgendwann total auf! Schreibrecht sind ok… Die meisten der Dateien sind *.php Files!

Die einzigste Lösung momentan ist, den Ordner neu zu erstellen und dann den alten vom Provider löschen lassen. Danach muss man jeden Tag mindestens 20.000 - 50.000 Dateien von Hand löschen.

Für Hilfe bzw Hinweise sind wir sehr dankbar…

Besten dank und schöne Grüße

nospamplease

Shop Version?
Update auf 4.4.8 sollte helfen.

salut,

“Fehler” dürfte in der Verwendung von “oxifcontent” liegen. In einer der Version wird dann die “sid” eingebunden. Dann läuft das Caching nicht mehr richtig und jeder oxifcontent-Block wird stets neu im tmp-Ordner abgelegt.

Unser Modul “TMP leeren” (im Modul-Connector enthalten), kann tmp-Dateien in dieser Größenordnung löschen. Es wird dann für das löschen ein Ticker verwendet um diese Anzahl zu bewältigen.

ceau

Vielen Dank für Eure Statements…, da muss ich mal schauen, was ich machen kann…!?
Vielleicht weiß ja noch jemand Rat!??!?

Ok, den Bug hab ich jetzt endlich im Bugtracking gefunden:

https://bugs.oxid-esales.com/view.php?id=1834

Ne Lösung steht da aber nicht wirklich oder bin ich blind?!?!

EDIT: Doch…updaten… :frowning:

EDIT 2. Vielleicht auch unter Performance --> “Artikelbeschreibung und Kategorienbeschreibung durch SMARTY ausführen” abstellen!!!

Fixed in Version 4.3.2 revision 27884

Sollte das immer noch der Fall sein, müsste man den Bug neu aufmachen.

auf welcher Version steht denn der Shop mit dem Problem?

Hallo Hebsacker,

leider cruist der Shop noch auf der alten Version rum:

OXID eShop Community Edition, Version 4.3.0

Ein Update wäre da natürlich unbedingt notwendig. Nur, wenn man so liest, was da dann wieder alles schief gehen kann…, oh jeh oh jeh. :frowning:

Wahrscheinlich werden wir nicht drum rum kommen…

Hat da jemand vielleicht noch den ein oder anderen Tipp!?
Was sollte man bei so einem Update unbedingt beachten!?!?

@ChristophH: Musst also nicht im Bugtracking neu aufmachen! :wink:

ein Update von 4.3.0 auf 4.3.2 sollte keine schwerwiegenden Probleme machen - das ist ja kein Riesenschritt

hier findest Du die Version 4.3.2 -> http://wiki.oxidforge.org/Downloads/4.3.2

und hier ne Anleitung -> http://www.oxid-esales.com/de/resources/help-faq/eshop-manual/von-einem-release-auf-das-naechste-updaten

Ganz wichtig! Immer ein Backup vorher machen und am besten erstmal in einer Testumgebung ausprobieren!

Ein Update auf die 4.3.2 ist unkritisch. Selbst ein Update auf die 4.4.8 sollte eher problemlos sein. Bei diesen Schritten hat sich soweit nur wenig am Admin geändert und alle Module sollten noch problemlos funktionieren.

Danke für die Info, Firefax! Wir haben jetzt erst mal ein php Script gecodet, welches den Inhalt des tmp Ordners löscht. Das ganz könnte man jetzt noch als Cronjob jede Nacht laufen lassen. Aber um ein update kommen wir wahrscheinlich nicht drum rum.

Werde es mal lokal testen und wenn es klappt, dann loslegen!

Danke an alle für die Infos! :slight_smile:

Hallo Leute, ich habe das Problem gestern auch gehabt und wie folgt gelöst:
(Shop läuft auf Debian Linux Lenny)
a) In der config.inc.php von Oxid den Pfad von /home/kunde/htdocs/tmp
auf /home/kunde/htdocs/tmp_neu umgestellt
b) den Apache restartet
c) Über Nacht mit dem midnight commander das komplette Verzeichnis /home/kunde/htdocs/tmp gelöscht
d) Das Verzeichnis mit /home/kunde/htdocs/tmp mit mkdir wieder neu
angelegt
e) mit chown die Rechte wieder angepasst
f) In der config.inc.php den Cache-Pfad erneut auf
die /home/kunde/htdocs/tmp zurückgesetzt
Nun ist alles gecleared. :slight_smile:
Ist nur ein Workaround, aber damit verschafft man sich erstmal Zeit bis zum nächsten Shop-Update. :wink:
P.S.: Das Tmp-Clearing-Module konnte bei mir leider nicht mehr ausgeführt werden, da der Shop sonst in einen Timeout lief

Hi degenhardt,

schön, das noch jemand das Problem hat…

Naja, schön ist das nicht wirklich, aber wenigstens sind wir nicht alleine.
Leider sind wir noch nicht zu einem Update gekommen (keine Zeit)
und mittlerweile werden es immer mehr Dateien.

Aber eigentlich hättest Du nur den TMP Folder umbenennen müssen udn danns chnell einen neuen anlegen, den Pfad brauchte dann eben nicht anpassen. Den Apache können wir leider nicht mal schnell neu starten…
[B]
Weiß jemand vielleicht welche Datei(en) für die Erstellung der TMP Files verantwortlich ist??? Vielleicht kann ich dann da mal nachschauen…[/B]

Ich weiß, wir kommen um ein Update nicht herum, aber so lange keine Zeit ist müssen
wir dem Problem eben so engegen wirken.

Ja, ich weiß…schön ist das nicht!

Okay, hab es selber rausgefunden. Die Datei die in dieser Version (4.3.0) dieses Verhalten produziert heisst:

block.oxifcontent.php

Zu finden ist diese Datei unter: …/core/smarty/plugins

block.oxifcontent.php Version 4.3.0:

 function smarty_block_oxifcontent( $params, $content, &$smarty, &$repeat)
{
    $myConfig = oxConfig::getInstance();

    $sIdent  = isset( $params['ident'] )?$params['ident']:null;
    $sOxid   = isset( $params['oxid'] )?$params['oxid']:null;
    $sAssign = isset( $params['assign'])?$params['assign']:null;
    $sObject = isset( $params['object'])?$params['object']:'oCont';

    if ($repeat) {
        if ( $sIdent || $sOxid ) {
            $oContent = oxNew( "oxcontent" );
            $blLoaded = $sOxid?$oContent->load( $sOxid ):$oContent->loadbyIdent( $sIdent );
            if ( $blLoaded && $oContent->oxcontents__oxactive->value ) {
                $smarty->assign($sObject, $oContent);
            }
        } else {
            $blLoaded = false;
        }
        $repeat = $blLoaded;
    } else {
        $content = oxUtilsView::getInstance()->parseThroughSmarty( $content, $sIdent.md5($content) );
        if ($sAssign) {
            $smarty->assign($sAssign, $content);
        } else {
            return $content;
        }
    }

}

So klappts nun auch mit den TMP Files:

function smarty_block_oxifcontent( $params, $content, &$smarty, &$repeat)
{
    $myConfig = oxConfig::getInstance();

    $sIdent  = isset( $params['ident'] )?$params['ident']:null;
    $sOxid   = isset( $params['oxid'] )?$params['oxid']:null;
    $sAssign = isset( $params['assign'])?$params['assign']:null;
    $sObject = isset( $params['object'])?$params['object']:'oCont';

    if ($repeat) {
        if ( $sIdent || $sOxid ) {
            $oContent = oxNew( "oxcontent" );
            $blLoaded = $sOxid?$oContent->load( $sOxid ):$oContent->loadbyIdent( $sIdent );
            if ( $blLoaded && $oContent->oxcontents__oxactive->value ) {
                $smarty->assign($sObject, $oContent);
            }
        } else {
            $blLoaded = false;
        }
        $repeat = $blLoaded;
    } else {
        $oStr = getStr();
        $blHasSmarty = $oStr->strstr( $content, '[{' );
        if ( $blHasSmarty  ) {
            $content = oxUtilsView::getInstance()->parseThroughSmarty( $content, $sIdent.md5($content) );
        }

        if ($sAssign) {
            $smarty->assign($sAssign, $content);
        } else {
            return $content;
        }
    }

}

Was 3 Zeilen so alles ausmachen können!

Seit diesem Update der Datei befinden sich - wenns hoch kommt - höchstens mal noch 200-400 Dateien im TMP Folder und wenn man sich ausloggt, dann werden sogar noch welche gelöscht. Coole Sache…, endlich funzt es wieder!

Falls also noch jemand diese Problem hat…, vielleicht hilft das ja dann auch!? :wink:

PS: Dank an gaertnermarkus, welcher den entscheidenden Tipp gegeben hat!!!