it-swarm.com.de

PHP Problem mit 7 Benutzersitzungen - Speichermodul konnte nicht initialisiert werden

Bei der Verwendung verschiedener PHP Framework-Sitzungstreiber mit PHP 7.0 ist ein Fehler aufgetreten. Dieses Problem trat ursprünglich bei der Verwendung des CodeIgniter-Datenbanktreibers auf und ich ging davon aus, dass es sich um ein CodeIgniter-Problem handelt, seitdem jedoch bei Treibern für mehrere Sitzungen und mehreren Frameworks aufgetreten ist. An dieser Stelle habe ich abgeschlossen sicher, dass die Art der Sitzung Treiber ist irrelevant - scheinbar zufällig, wird die Anwendung zum Absturz bringen und die Protokolle (ich habe beide Apache und PHP-FPM + nginx versucht) füllen sich mit dem folgenden:

Schwerwiegender PHP-Fehler: session_start (): Speichermodul: user konnte nicht initialisiert werden (Pfad: [was auch immer ich in meinem php.ini-Pfad habe])

Die Treiber verwende ich nicht die Werte in der php.ini und unabhängig davon gesetzt verwenden, ob ich die session.save_handler auf Dateien festgelegt, redis, etc in der php.ini und unabhängig vom Weg, den ich gesetzt (Redis-Server, wenn redis, voll beschreibbarer Ordner mit aktivierten Dateien) treten die Fehler auf. Der Pfad hier sollte niemals getroffen werden, es sei denn, eine native "session_start ()" wird in einer PHP-Datei außerhalb des Frameworks aufgerufen. Das Aufrufen von "session_start ()" außerhalb des Frameworks funktioniert auch einwandfrei. Es ist also klar, dass PHP auf den Pfad zugreifen kann. Es ist, als würde der Session-Treiber irgendwann zu einem Hybrid aus dem Framework-Treiber und den Einstellungen in der php.ini. Die Fehlermeldung hat immer "user" für den session.save_handler, das wird also offensichtlich nicht aus der php.ini gezogen ... aber der Pfad ist. Warum sollte das passieren? Dies ist eines dieser Probleme, das schwer zu beschreiben ist, bis Sie es erlebt haben ... und es ist schwierig zu reproduzieren, da alles auch für Hunderte von Sitzungen gut zu funktionieren scheint (bis es plötzlich nicht mehr funktioniert). Ein Neustart von Apache behebt das Problem ebenfalls nicht - es gibt eine Reihe von Problemen, und ich starte den Computer am Ende nur neu, um Ausfallzeiten zu vermeiden. Offensichtlich wird die Maschine PHP 7 jetzt aus der Lastausgleichsrotation herausgezogen ... aber ich hatte gehofft, die Dinge jetzt herauszufinden.

Ich habe das Problem mit PHPerfahren _ 7.0 RC5, RC6, RC8 & kompiliert auf meinem eigenen sowie den neuesten Ondřej Surý PPA auf Ubuntu 15.10 Wily (7.0.0-2 + ​​deb.sury.org ~ gerissenen +1). Ich habe das Problem auf CodeIgniter & Symfony erfahren und habe das Problem unabhängig von der Art des Treibers im Rahmen (Dateien, Datenbank, redis) oder den session.save_handler gesetzt in der php.ini (was wiederum irrelevant früher erfahren sollte hier dachte ich aber nur, es sollte erwähnt werden). Ich versuche immer wieder, Kombinationen zu finden und Dinge rauszuwerfen, und dieses Problem tritt jedes Mal auf (manchmal dauert es mehr als 12 Stunden, abhängig vom Traffic auf der Website).

Vielen Dank für jede Hilfe, die Sie zur Verfügung stellen können! Ich bin offen für Vorschläge und bereit, an dieser Stelle alles zu versuchen.

3
DrBlueSpruce

Dieser Fehler tritt auf, wenn die Funktion open() des Sitzungshandlers nicht den booleschen Wert TRUE zurückgibt, was offensichtlich einen Fehler bedeutet.

Die Verbindung zu einer Datenbank kann fehlschlagen, eine Datei kann nicht geöffnet werden, ein nicht vorhandenes Verzeichnis usw. - dies hängt davon ab, was der Sitzungshandler tatsächlich verwendet.

6
Narf

die Funktion _open sollte true zurückgeben, um diesen Fehler zu vermeiden.

Es darf weder null noch leer sein, egal welche Datenbank oder Datei wir verwenden.

Wenn wir die Datenbank zum Speichern von Sitzungsdaten verwenden, lassen wir sie leer oder geben keine Booleschen Werte zurück. das ist der Hauptgrund für diesen Fehler.

class session_handler
{
    public function __construct()
    {
        session_set_save_handler(
            array($this, "_open"),
            array($this, "_close"),
            array($this, "_read"),
            array($this, "_write"),
            array($this, "_destroy"),
            array($this, "_gc")
        );
    }

    public function _open($savePath, $sessionId)
    {
        return true;
    }

    public function _close() {  }    
    public function _read($id) {  }
    public function _write($id, $data) {  }
    public function _destroy($id) {  }
    public function _gc($max) {  }
}

Es ist nur für PHP 7. Ich weiß nicht, ob es ein Fehler ist oder nicht.

5
Moin Uddin

Dies ist normalerweise darauf zurückzuführen, dass die Sitzung keine Verbindung zu dem von ihr verwendeten Treiber (Datei, Datenbank) herstellen kann.

Ich habe das Problem behoben, indem ich mir die Datei config.php angesehen habe

    $config['sess_driver'] = 'database';
    $config['sess_cookie_name'] = 'ci_session';
    $config['sess_expiration'] = 7200;
    $config['sess_save_path'] = 'ci_sessions';
    $config['sess_match_ip'] = FALSE;
    $config['sess_time_to_update'] = 300;
    $config['sess_regenerate_destroy'] = FALSE;

Da ich eine Datenbank verwendet habe, bedeutet dies, dass die Verbindung aus irgendeinem Grund nicht hergestellt werden kann! (Bei Dateien ist es wahrscheinlich nicht zulässig, die zwischengespeicherten Dateien zu schreiben.)

Als nächstes schaltete ich das Protokoll ein

    $config['log_threshold'] = 4;

Where 4 = All Messages .. Dann aktualisiere die Seite und jetzt habe ich in application/logs eine Datei mit dem Namen log-#.php, wobei # ein Datum ist.

    INFO - 2017-08-30 10:05:41 --> Database Driver Class Initialized
    ERROR - 2017-08-30 10:05:41 --> Severity: Warning --> mysqli::real_connect(): (HY000/1045): Access denied for user 'user'@'localhost' (using password: YES) /var/system/database/drivers/mysqli/mysqli_driver.php 202
    ERROR - 2017-08-30 10:05:41 --> Unable to connect to the database
    ERROR - 2017-08-30 10:05:41 --> Severity: Warning --> mysqli::real_connect(): (HY000/1045): Access denied for user 'user'@'localhost' (using password: YES) var/system/database/drivers/mysqli/mysqli_driver.php 202
    ERROR - 2017-08-30 10:05:41 --> Severity: Error --> session_start(): Failed to initialize storage module: user (path: ci_sessions) /var/system/libraries/Session/Session.php 140

Ich stelle also nur sicher, dass der Benutzer auf die Datenbank zugreifen kann und es funktioniert.

1
Saln3t

In meinem Fall verwende ich PHP ver 5.6 mit CI ver 3.4 (Codeigniter) Server: BIGROCK Ich habe diese Probleme auf meinem Live-Server gefunden.

Dann nach langer Zeit. Ich habe gerade versucht, meine Datenbank zu löschen und neu zu erstellen.

Dann wusste nur ich, dass ich Erlaubnis dem Benutzer nicht gegeben habe, auf die Datenbank zuzugreifen.

Also, wenn Sie fertig sind, erstellen Sie Ihre Datenbank und Benutzer, sollten Sie wahrscheinlich Berechtigungen (Previlleges) für den Benutzer, um auf die Datenbank zuzugreifen.

Lass es mich wissen, wenn es in deinem Fall nützlich ist. Vielen Dank.

1

Dies ist nur dann der Fall, wenn der session_save_path ungültig ist. Wenn Sie Ihre Sitzungsdaten in einer Datenbank speichern, muss die Sitzungstabelle erstellt werden, damit CI die Daten speichert, ansonsten tritt dieser Fehler auf. Hoffnung hat jemandem geholfen

0
Joseph Daudi

Ich habe beschlossen, mein System zu migrieren und einige dringend benötigte Aktualisierungen vorzunehmen. Ich bin mit Codeigniter 3 und PHP 7.2 auf dieses Problem gestoßen. Nachdem ich das Problem gefunden hatte, wurde mir klar, wie lächerlich es war, und ich fragte mich, warum ich es nicht früher herausgefunden hatte. ????

Jedenfalls ist hier zumindest für mich die Lösung.

Stellen Sie sicher, dass memcacheD installiert ist:

Sudo apt-get update
Sudo apt-get install php7.2-memcached

Wenn das in Ordnung ist, können wir alles andere überprüfen.

In der Konfigurationsdatei von Codeigniter "/application/config/config.php" gibt es einen Abschnitt, in dem die Sitzungsoptionen angegeben werden:

$config['sess_driver'] = 'memcached';
$config['sess_cookie_name'] = 'some_session_name';
$config['sess_expiration'] = 7200;
$config['sess_save_path'] = NULL;
$config['sess_match_ip'] = FALSE;
$config['sess_time_to_update'] = 300;
$config['sess_regenerate_destroy'] = FALSE;

Die Zeile, die für mich geändert werden musste, war diese Zeile:

$config['sess_save_path'] = NULL;

Stellen Sie sicher, dass Sie einen gültigen Pfad angeben, wie im CI3-Handbuch beschrieben. Die richtige Einstellung sieht folgendermaßen aus:

$config['sess_driver'] = 'memcached';
$config['sess_save_path'] = 'localhost:11211';

Stellen Sie sicher, dass Sie "localhost" ändern, um den Speicherort Ihres zwischengespeicherten Servers wiederzugeben.

Für weitere Informationen siehe - Codeignier Session Manual

Schauen Sie auch hier: Unterstützung für PHP-MemcacheD-Sitzungen

Falls der Kommentar auf der Seite entfernt wird, poste ich hier:

Wenn Sie die Erweiterung 'memcacheD' und nicht 'memcache' (es gibt zwei verschiedene Erweiterungen) für die Sitzungssteuerung verwenden möchten, sollten Sie darauf achten, die Datei php.ini zu ändern

Die meisten Webressourcen von Google basieren auf memcache, da es sich um eine frühere Version als memcacheD handelt. Sie werden wie folgt sagen

session.save_handler = memcache session.save_path = "tcp: // localhost: 11211"

Aber es ist nicht gültig, wenn es um memcacheD geht

du solltest die php.ini so modifizieren

session.save_handler = zwischengespeichert session.save_path = "localhost: 11211"

Schau, es gibt keinen Protokollidentifikator

Zum Testen habe ich dies getan, um den Benutzer zu veranlassen, dass PHP selbst kein Problem beim Zugriff auf memcacheD hat:

session_start();

    header('Content-Type: text/plain');
    session_start();
    if(!isset($_SESSION['visit']))
    {
        echo "This is the first time you're visiting this server\n";
        $_SESSION['visit'] = 0;
    }
    else
            echo "Your number of visits: ".$_SESSION['visit'] . "\n";

    $_SESSION['visit']++;

    echo "Server IP: ".$_SERVER['SERVER_ADDR'] . "\n";
    echo "Client IP: ".$_SERVER['REMOTE_ADDR'] . "\n";
    print_r($_COOKIE);

$servers = explode(",", ini_get("session.save_path"));
$c = count($servers);
for ($i = 0; $i < $c; ++$i) {
  $servers[$i] = explode(":", $servers[$i]);
}


$mem = new memcached();

$mem->addServer('127.0.0.1', '11211', '1');
$mem->set('011', 'Hello There');

print_r($mem->get('011'));

print_r($mem->getAllKeys());

Dadurch konnte ich sehen, dass memcacheD in Ordnung war.

Auch in Ihrer php.ini gibt es einige Optionen, auf die Sie achten müssen. Suchen Sie einfach nach [session] oder session.save_path. CI3 hat angegeben, dass diese Option aus der Datei php.ini nicht verwendet wird. Es ist jedoch wahrscheinlich sinnvoll, diese Option festzulegen, wenn Sie memcacheD außerhalb des Frameworks und aus Gründen der Konsistenz verwenden möchten.

Dies beginnt um die Zeile ~ 1327 in der php.ini-Datei:

[Session]
; Handler used to store/retrieve data.
; http://php.net/session.save-handler
session.save_handler = memcached

; Argument passed to save_handler.  In the case of files, this is the path
; where data files are stored. Note: Windows users have to change this
; variable in order to use PHP's session functions.
;
; The path can be defined as:
;
;     session.save_path = "N;/path"
;
; where N is an integer.  Instead of storing all the session files in
; /path, what this will do is use subdirectories N-levels deep, and
; store the session data in those directories.  This is useful if
; your OS has problems with many files in one directory, and is
; a more efficient layout for servers that handle many sessions.
;
; NOTE 1: PHP will not create this directory structure automatically.
;         You can use the script in the ext/session dir for that purpose.
; NOTE 2: See the section on garbage collection below if you choose to
;         use subdirectories for session storage
;
; The file storage module creates files using mode 600 by default.
; You can change that by using
;
;     session.save_path = "N;MODE;/path"
;
; where MODE is the octal representation of the mode. Note that this
; does not overwrite the process's umask.
; http://php.net/session.save-path
;session.save_path = "/var/lib/php/sessions"
session.save_path = "locahost:11211"

Ein weiterer Ort zum Überprüfen der Einstellungen ist die Konfigurationsdatei des mecacheD-Servers. Je nach System kann der Standort variieren. Für mich befand es sich im Verzeichnis/ etc /.

/etc/memcached.conf

Bild als Referenz für die Fehler, die ich bekommen habe:

 Image of Errors

0
toystory

Wir sind gerade auf ein ähnliches Problem gestoßen, bei dem wir unseren eigenen benutzerdefinierten Handler mit session_set_save_handler so eingestellt haben, dass er in den Memcached-Modus wechselt.

Warning: session_write_close(): Failed to write session data (user). Please verify that the current setting of session.save_path is correct (/var/lib/php/7.0/session) in Unknown on line 0

Es stellt sich heraus, dass die Funktion "write" einen booleschen Wert zurückgeben muss (genau wie start), aber es ist die einzige Funktion für session_set_save_handler, die keine Rückgabewerte in den offiziellen Dokumenten PHP erwähnt. Während es so aussieht, als würde es zum standardmäßigen Sitzungshandler zurückkehren, wird nur der Fehler für den standardmäßigen Sitzungshandler ausgegeben.

Der Fehler und die Dokumentseiten hätten uns niemals zu einer Lösung geführt ...

0
ahamilton9

Ich glaube, ich habe das Problem herausgefunden; Ich werde diese Frage schließen. Grundsätzlich sieht es so aus, als würde ein Problem mit dem Framework-Sitzungstreiber/config (SQL-Verbindungen überschritten, Speichermangel bei Redis usw.) auf den Versuch zurückgreifen, den in der Datei php.ini festgelegten Pfad sess.save_path zu verwenden, während weiterhin der Treiber/config verwendet wird Framework-Sitzungstreiber. Sofern der Framework-Treiber nicht mit dem Standard-Pfad sess.save_path in der Datei php.ini kompatibel ist, tritt dieser Fehler auf. Für mich wäre es sinnvoller, auch auf den sess.save_handler in der php.ini zurückzugreifen ... aber wenn dies ein Problem ist, gibt es offensichtlich größere Probleme mit der App-Konfiguration, die behoben werden müssen.

Es ist nicht der Fehler selbst, der die Sitzungen unterbricht. Es war ein zugrunde liegendes Problem mit den Framework-Sitzungstreibern. Ich fühle mich dumm ... aber die Protokolle haben mich im Grunde auf eine wilde Gänsejagd geschickt. Durch einen Neustart von nginx oder Apache konnte das Problem nicht behoben werden, da es sich um ein anderes Problem handelte. Ich glaube, es gibt immer noch Probleme mit den verfügbaren PHP 7 Redis-Bibliotheken, und die SQL-Probleme waren meine Schuld. Nachdem anscheinend mehrere Kombinationen ausprobiert wurden und das gleiche Ergebnis erzielt wurde, wirkte das Problem kryptischer. Ich erhalte immer noch seltsame Fehler bei der Verwendung von Redis-Sitzungen auf PHP 7, aber wie gesagt, die PHP 7-Redis-Bibliothek ist nicht sehr ausgereift.

0
DrBlueSpruce

ich ändere meine php.ini:

session.save_path = "N;/path" **to** session.save_path = "/tmp"

und ich starte mein php7-fpm neu

0
dickyf