Ankündigung

Einklappen
Keine Ankündigung bisher.

php7 - Problem mit session_write_close():

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • php7 - Problem mit session_write_close():

    Hallo Forum,

    ich werde einfach nicht schlau aus folgendem Fehler.

    PHP Warning: session_write_close(): Session callback expects true/false
    PHP 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/sessions)
    Das Problem soll nicht im Code sondern in der config von php liegen. (Worauf "Failed to write session data" schließen lässt.)

    Ich habe die Berechtigung des Ordners "/var/lib/php/sessions" so angepasst das php schreiben kann. Jedoch ohne Erfolg. Anschließend habe ich zum Test den Pfad in der php.ini in den Ordner gelegt in dem das Projekt liegt - um somit sicher zu gehen, dass es keine Berechtigungsprobleme vorliegen.
    In den Logs konnte ich feststellen, dass die Pfadänderung übernommen wurde. Jedoch wird nichts geschrieben.

    Konnte jemand ein ähnliches Problem bereits lösen?

    ich nutze php7.0 und mariaDB 10.1

  • #2
    Beheb den ersten Fehler, dann sollte der zweite von selbst verschwinden.

    Kommentar


    • #3
      Ich finde die Lösung einfach nicht. Hat jemand einen Tipp?

      Kommentar


      • #4
        Laut Fehlermeldung ist der Return value von session_write_close() kein Boolean ...

        Kommentar


        • #5
          Zeige mal deinen Code, wo dieser Fehler bei Ausführung vorkommt.

          Kommentar


          • #6
            Zitat von deleted Beitrag anzeigen
            Das Problem soll nicht im Code sondern in der config von php liegen. (Worauf "Failed to write session data" schließen lässt.)
            Nur wenn session_write_close nicht manuell von Deinem Code aufgerufen wird. Ist das denn so?

            Zitat von deleted Beitrag anzeigen
            Ich habe die Berechtigung des Ordners "/var/lib/php/sessions" so angepasst das php schreiben kann.
            Das bedeutet was genau? Wer ist der Eigentümer des Verzeichnisses? (Nutzer und Gruppe)

            Zitat von deleted Beitrag anzeigen
            Anschließend habe ich zum Test den Pfad in der php.ini in den Ordner gelegt in dem das Projekt liegt
            Das ist nicht nötig!

            Wo die PHP.ini liegen muss hängt von Deiner distri ab. Bei Debian basierten halbwegs aktullen Systemen wie Ubuntu liegt die irgenwo in /etc/php/…

            Wenn Du nicht weist welche die richtige ini ist mach Dir nen Script:

            PHP-Code:
            <?php

            phpinfo
            ();
            ruf das über den Webserver auf und schaue im oberen Bereich der Ausgabe im Eintrag "Configuration File (php.ini) Path" nach welche ini geladen wird.

            Zitat von deleted Beitrag anzeigen
            ich nutze php7.0 und mariaDB 10.1
            Warum kein aktuelles PHP? PHP 7.0 ist schon ~2 Jahre alt. Und welches DBMS Du nutzt ist für das Problem nicht von Bedeutung

            Kommentar


            • #7
              Zitat von Messier 1001 Beitrag anzeigen

              Nur wenn session_write_close nicht manuell von Deinem Code aufgerufen wird. Ist das denn so?
              Da ich den Code nicht selbst schrieb, habe ich die Suchfunktion genutzt. Der einzige Eintrag ist besagter "session_write_close();" ganz am Ende.

              Zitat von Messier 1001 Beitrag anzeigen
              Das bedeutet was genau? Wer ist der Eigentümer des Verzeichnisses? (Nutzer und Gruppe)
              Standartmäßig war Nutzer & Gruppe "Root" - Ich hatte es erfolglos in "www:data" und "php" geändert. Bei beiden versuchen jeweils für Nutzer & Gruppe.

              Zitat von Messier 1001 Beitrag anzeigen
              Das ist nicht nötig!

              Wo die PHP.ini liegen muss hängt von Deiner distri ab. Bei Debian basierten halbwegs aktullen Systemen wie Ubuntu liegt die irgenwo in /etc/php/…

              Wenn Du nicht weist welche die richtige ini ist mach Dir nen Script:

              PHP-Code:
              <?php

              phpinfo
              ();

              ruf das über den Webserver auf und schaue im oberen Bereich der Ausgabe im Eintrag "Configuration File (php.ini) Path" nach welche ini geladen wird.
              Dies auch nur zum Test. Es ist wieder der Standartpfad hinterlegt. Den Test habe ich ebenfalls schon gemacht um diese Fehlerquelle auszuschließen. Ich bearbeite die richtige .ini

              Zitat von Messier 1001 Beitrag anzeigen
              Warum kein aktuelles PHP? PHP 7.0 ist schon ~2 Jahre alt. Und welches DBMS Du nutzt ist für das Problem nicht von Bedeutung
              Ich nutze Debian und das ist die aktuellste Version, welche in den Paketquellen vorhanden ist.

              Kommentar


              • #8
                Zitat von deleted Beitrag anzeigen
                Da ich den Code nicht selbst schrieb, ...
                Das war mehr als offensichtlich, daher auch meine Frage in Beitrag #5. die du wohl überlesen hast.

                Zudem:
                Zitat von deleted Beitrag anzeigen
                Das Problem soll nicht im Code sondern in der config von php liegen.
                Das vermutest du oder bist du dir zu 100% sicher?

                Wenn du dir das Handbuch zur Hand nimmst, steht dort unter anderem, dass diese Funktion nicht notwendig ist, wenn du keine konkurrierenden Schreibzugriffe auf die Session hast.

                Da du aber wohl auch an der php.ini rum gespielt hast, ist nicht auszuschliessen, dass du jetzt mehr kaputt gemacht hast als es vorher schon der Fall war.

                Verwendest du denn Frames?
                Wenn ja, schmeiss das Script besser gleich weg, da es durchgerostet ist.

                OT
                Standartpfad muss standardpfad heissen.
                /OT

                Kommentar


                • #9
                  Schau ob du in den Script irgendwo session_set_save_handler(...) findest. Der erste Fehler deutet auf ein eigenen Session Handler hin. Die zweite Meldung wäre damit quatsch, bzw. der Hinweis mit dem Pfad..

                  Kommentar


                  • #10
                    protestix
                    Fast richtig. Überlesen habe ich es nicht, jedoch habe ich dich beim Antworten einfach vergessen. Sorry.
                    Es handelt sich um das Projekt gnu-social, welches etwas eingeschlafen ist. Deswegen bin ich auch ziemlich froh, das meine php Version nicht noch neuer ist. Und da ich wie angesprochen keine Kenntnisse in php habe, fragte ich zuerst direkt bei dem Projekt nach, dort wurde mir gesagt, das es am php / Webserver liegt. Daher bin ich zuerst dort auf die Suche gegangen. Alle Änderungen an der php.ini habe ich in den Originalzustand zurückversetzt.

                    erc

                    Ja, es ist vorhanden:

                    PHP-Code:
                    static function setSaveHandler()
                        {
                            
                    self::logdeb("setting save handlers");
                            
                    $result session_set_save_handler('Session::open''Session::close''Session::read',
                                                               
                    'Session::write''Session::destroy''Session::gc');
                            
                    self::logdeb("save handlers result = $result");

                            
                    // PHP 5.3 with APC ends up destroying a bunch of object stuff before the session
                            // save handlers get called on request teardown.
                            // Registering an explicit shutdown function should take care of this before
                            // everything breaks on us.
                            
                    register_shutdown_function('Session::cleanup');

                            return 
                    $result;
                        } 
                    Auf den Hinweis bin ich nicht eingegangen, da dort von php 5.3 gesprochen wurde. Zumal die Handhabung von session_write_close(); wohl in php7 geändert wurde.

                    Entschuldigt, dass ich keine genaueren Auskünfte geben kann, jedoch bin ich wie zu sehen kein Programmierer.

                    Kommentar


                    • #11
                      Jetzt wäre es natürlich hilfreich wenn du PHP könntest. Mit session_set_save_handler() wird die Standardfunktionalität von PHP überschreiben und gegen eine eigene Implementierung getausch, Es gibt eine Klasse "Session" in dem Projekt und die funktioniert nicht richtig. Da musst du schauen warum die nicht richtig funktioniert. Alternativ und ganz dreckig, du schreibst in die Funktion ganz oben return true; rein und schaust was passiert. Damit wird das Session Handling von PHP verwendet.

                      Kommentar


                      • #12
                        Ist sogar schon als BUG hinzugefügt worden..

                        Du hast nun mehrere Optionen:
                        • Entweder warten bis der Fehler behoben wurde bzw, die Software an PHP7 angepasst wurde.(kann Jahre dauern)
                        • Selber Hand anlegen, heisst PHP lernen und den Kram umschreiben,(hat schon manche in den Wahn getrieben wie man so liest)
                        • Dritte Möglichkeit wäre, du verzichtest auf die Software und suchst dir eine andere.(Meine pers. Empfehlung).

                        Kommentar


                        • #13
                          erc hat das einen bestimmten Grund, dass man seinen eigenen Session_handler schreibt?

                          Kommentar


                          • #14
                            protestix der post ist von mir. Dort steht auch der Hinweis, dass es am php / Webserver liegen soll.

                            erc
                            Wo genau schreibe ich das "return true" hin? Dies habe ich bereits in einem anderen Forum gelesen und es am Ende der Funktion geschrieben. Es hatte jedoch keine Auswirkung.
                            Du kennst dich aus mit dem Projekt, da du die Klasse "Session" ansprichst?

                            Um den Bug richtig zu beheben, wie hoch wäre der Aufwand? Könnt Ihr das einschätzen?

                            Kommentar


                            • #15
                              Zitat von protestix Beitrag anzeigen
                              erc hat das einen bestimmten Grund, dass man seinen eigenen Session_handler schreibt?
                              Ein allgemeinen Gund gibt es dafür nicht. Den Hauptgrund sehe ich in Load Balancing. Der Rest würde ich eher als spezialfall ansehen. Für das Load Balancing musst du aber auch nicht zwingend ein eigenen Handler schreiben. Die PHP Extensions von memcached, redis, usw. bringen schon fertige Implementierungen mit. Wobei man da auch vorsichtig sein muss. Z.B. die Redis implementierung unterstützt kein Locking. Je nach Anwendungsfall kann das mehr oder wenig katastrophal sein. Da musst du dann ggf. selbst was in PHP schreiben.

                              Zitat von deleted Beitrag anzeigen
                              protestix der post ist von mir. Dort steht auch der Hinweis, dass es am php / Webserver liegen soll.
                              Das Problem auf was er verweist ist was anderes.

                              ercWo genau schreibe ich das "return true" hin? Dies habe ich bereits in einem anderen Forum gelesen und es am Ende der Funktion geschrieben. Es hatte jedoch keine Auswirkung.[/QUOTE]

                              Direkt über self::logdeb("setting save handlers");

                              PHP-Code:
                              static function setSaveHandler()
                              {
                                  return 
                              true;
                                  ...

                              Wahrscheinlich wird sich der Fehler aber an einer anderen Stelle mit anderen Symptomen zeigen.

                              Kommentar

                              Lädt...
                              X