# Frontend-Timeout wesentlich kürzer als gc\_maxlifetime?

**URL:** <https://forum.shopware.com/t/frontend-timeout-wesentlich-kurzer-als-gc-maxlifetime/55926>\
**Category:** Administration\
**Created:** [23. Oktober 2018 um 09:49 UTC](https://forum.shopware.com/t/frontend-timeout-wesentlich-kurzer-als-gc-maxlifetime/55926 "2018-10-23T09:49:02Z")\
**Posts on this page:** 13\
**Page:** 1

<div class="post-metadata">

**Author:** ![sunflower](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.shopware.com/sunflower/32/8100_2.png) [@sunflower](https://forum.shopware.com/u/sunflower)\
**Post date:** [23. Oktober 2018 um 09:49 UTC](https://forum.shopware.com/t/frontend-timeout-wesentlich-kurzer-als-gc-maxlifetime/55926/1 "2018-10-23T09:49:02Z")

</div>

Hallo zusammen,

was kann das Beenden der PHP-Session im Frontend auslösen?

Kunde ist eingelogged, legt Artikel in den Warenkorb und lässt den PC einfach so stehen. Es wird nicht daran gearbeitet. Wenn man 20 bis 30 Minuten später weitermachen möchte sieht es auf den ersten Blick “normal” aus, die Anzahl der Artikel im Warenkorb werden im Icon noch angezeigt. Klar, es wurde ja auch keine Seite neu geladen. Wenn nun ein weiterer Artikel in den Warenkorb gelegt wird ist der bestehende Warenkorb leer und nur der neue Artikel drin. Ein genauerer Bilck zeigt dass man nicht mehr angemeldet ist. Die gc\_maxlifetime haben wir auf 28800 gesetzt, das sollten doch eigentlich 8 Stunden sein.

Ein Löschen des Cache im Backend des Shops scheint die PHP-Sessions mit angemeldeten Usern nicht zu beenden.

Was kann da noch eine Ursache sein?

Grüße  
sunflower

---

<div class="post-metadata">

**Author:** ![Moritz\_Naczenski](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.shopware.com/moritz_naczenski/32/7792_2.png) [@Moritz\_Naczenski](https://forum.shopware.com/u/Moritz_Naczenski)\
**Post date:** [23. Oktober 2018 um 10:20 UTC](https://forum.shopware.com/t/frontend-timeout-wesentlich-kurzer-als-gc-maxlifetime/55926/2 "2018-10-23T10:20:41Z")

</div>

Was zeigt die Systeminfo denn an?  
Schau mal in die s\_core\_sessions ob die Zeit da zusammenpasst und den Wert deiner PHP-Einstellung hat.

Du kannst das in Shopware auch über die config.php setzen:

```
    'session' => [
        'gc_maxlifetime' => 8000,
    ],

```

&nbsp;

---

<div class="post-metadata">

**Author:** ![sunflower](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.shopware.com/sunflower/32/8100_2.png) [@sunflower](https://forum.shopware.com/u/sunflower)\
**Post date:** [23. Oktober 2018 um 10:41 UTC](https://forum.shopware.com/t/frontend-timeout-wesentlich-kurzer-als-gc-maxlifetime/55926/3 "2018-10-23T10:41:46Z")

</div>

Hallo Moritz,

Systeminfo:

![](https://europe1.discourse-cdn.com/flex013/uploads/shopware/original/2X/f/fe7691e5ea8eef93b0fb277565e6847074f265e6.jpeg)

![](https://europe1.discourse-cdn.com/flex013/uploads/shopware/original/2X/4/4dbaf533762cdd1001fe2c4c7a8548e843988c7a.jpeg)

Was meinst Du mit s\_core\_sessions? Die Tabelle, bzw. die Timetamps darin?

Grüße  
sunflower

---

<div class="post-metadata">

**Author:** ![Moritz\_Naczenski](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.shopware.com/moritz_naczenski/32/7792_2.png) [@Moritz\_Naczenski](https://forum.shopware.com/u/Moritz_Naczenski)\
**Post date:** [23. Oktober 2018 um 10:54 UTC](https://forum.shopware.com/t/frontend-timeout-wesentlich-kurzer-als-gc-maxlifetime/55926/4 "2018-10-23T10:54:22Z")

</div>

Ja, genau. Die Tabelle s\_core\_sessions.

Du könntest mal die Unix-Timestamps vergleichen, ob die zu der eingestellten Session-Zeit passen.

---

<div class="post-metadata">

**Author:** ![sunflower](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.shopware.com/sunflower/32/8100_2.png) [@sunflower](https://forum.shopware.com/u/sunflower)\
**Post date:** [16. November 2018 um 09:42 UTC](https://forum.shopware.com/t/frontend-timeout-wesentlich-kurzer-als-gc-maxlifetime/55926/5 "2018-11-16T09:42:25Z")

</div>

Hallo Moritz,

nun möchte ich an diesem Thema weitermachen. Habe immer noch die Beschwerden der User das nach ca. 20 bis 30 Minuten die Abmeldung erfolgt.  
Hier die Timestamps:

 ![](https://europe1.discourse-cdn.com/flex013/uploads/shopware/original/2X/3/3396d1817db52fb1aa3a670e57354d5b5bdd8734.jpeg)

Daraus kann ich erkennen, dass das expiry immer ca. die angesprochenen 20 bis 30 Min. sind und nicht die laut gc\_maxlifetime eingestellten 8 Stunden.  
Oder sehe ich da etwas falsch?

Müsste das expire nicht mit jedem modified-Zugriff automatisch erhöht werden?

Grüße  
sunflower

&nbsp;

---

<div class="post-metadata">

**Author:** ![Moritz\_Naczenski](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.shopware.com/moritz_naczenski/32/7792_2.png) [@Moritz\_Naczenski](https://forum.shopware.com/u/Moritz_Naczenski)\
**Post date:** [16. November 2018 um 09:52 UTC](https://forum.shopware.com/t/frontend-timeout-wesentlich-kurzer-als-gc-maxlifetime/55926/6 "2018-11-16T09:52:47Z")

</div>

Mitlerweile kam da ein Bug rein: [Shopware Issuetracker](https://issues.shopware.com/issues/SW-22825)

> <https://github.com/shopware/shopware/blob/8ead07a2262303447e553c98641f7241401fb93b/engine/Shopware/Core/sAdmin.php#L866>

Trag da mal dein gc\_maxlifetime ein statt die 7200.

&nbsp;

---

<div class="post-metadata">

**Author:** ![sunflower](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.shopware.com/sunflower/32/8100_2.png) [@sunflower](https://forum.shopware.com/u/sunflower)\
**Post date:** [16. November 2018 um 16:45 UTC](https://forum.shopware.com/t/frontend-timeout-wesentlich-kurzer-als-gc-maxlifetime/55926/7 "2018-11-16T16:45:36Z")

</div>

Uh…, Source patchen ![Lips-are-sealed](https://europe1.discourse-cdn.com/flex013/uploads/shopware/original/1X/010e22b531eb3c7c1f8923f227860da8f5114885.png "Lips-are-sealed")

Wenns hilft, mal sehen.

---

<div class="post-metadata">

**Author:** ![sunflower](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.shopware.com/sunflower/32/8100_2.png) [@sunflower](https://forum.shopware.com/u/sunflower)\
**Post date:** [21. November 2018 um 11:53 UTC](https://forum.shopware.com/t/frontend-timeout-wesentlich-kurzer-als-gc-maxlifetime/55926/8 "2018-11-21T11:53:41Z")

</div>

Leider hilft es nicht. ![Crying](https://forum.shopware.com/plugins/CKEditor/plugins/smiley/images/crying.png "Crying")

Ich habe diese Zeile brachial ersetzt und natürlich Cache gelöscht.

```
//$timeOut = !empty($timeOut) ? $timeOut : 7200;
$timeOut = 28800;

```

Trotzdem habe ich in der Tabelle s\_core\_sessions immer eine Differenz von ~ 24 Min. zwischen modified und expiry.

---

<div class="post-metadata">

**Author:** ![sunflower](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.shopware.com/sunflower/32/8100_2.png) [@sunflower](https://forum.shopware.com/u/sunflower)\
**Post date:** [28. November 2018 um 07:58 UTC](https://forum.shopware.com/t/frontend-timeout-wesentlich-kurzer-als-gc-maxlifetime/55926/9 "2018-11-28T07:58:01Z")

</div>

Immer noch kein Erfolg, timeout bleibt bei ~ 24 Min.&nbsp; ![Crying](https://europe1.discourse-cdn.com/flex013/uploads/shopware/original/1X/3d74433e0d4d6cb84e92906c2faceb6b50db91bf.png "Crying")

Wenn ich mir die Funktion sCheckUser ansehe kann ich da nichts vom Schreiben in die s\_core\_sessions erkennen. Da ist für mich nur die s\_user zu sehen. Evtl. habe ich ja was nicht kapiert.

Wann wird sCheckUser aufgerufen? Nur bei der Anmeldung oder auch zyklisch während der Benutzer angemeldet ist?

Mir ist noch eine andere Stelle aufgefallen:

PdoSessionHandler.php  
&nbsp;

```
   /**
     * {@inheritdoc}
     */
    public function write($sessionId, $data)
    {
        $maxlifetime = (int) ini_get('session.gc_maxlifetime');

        try {
            // We use a single MERGE SQL query when supported by the database.
            $mergeStmt = $this->getMergeStatement($sessionId, $data, $maxlifetime);
            if (null !== $mergeStmt) {
                $mergeStmt->execute();

                return true;
            }

            $updateStmt = $this->pdo->prepare(
                "UPDATE $this->table SET $this->dataCol = :data, $this->expiryCol = :expiry, $this->timeCol = :time WHERE $this->idCol = :id"
            );
            $updateStmt->bindParam(':id', $sessionId, \PDO::PARAM_STR);
            $updateStmt->bindParam(':data', $data, \PDO::PARAM_LOB);
            $updateStmt->bindValue(':expiry', time() + $maxlifetime, \PDO::PARAM_INT);
            $updateStmt->bindValue(':time', time(), \PDO::PARAM_INT);
            $updateStmt->execute();

```

Hier wird doch auf die gc\_maxlifetime zugegriffen und ein timeout berechnet.

&nbsp;

---

<div class="post-metadata">

**Author:** ![sunflower](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.shopware.com/sunflower/32/8100_2.png) [@sunflower](https://forum.shopware.com/u/sunflower)\
**Post date:** [28. November 2018 um 08:20 UTC](https://forum.shopware.com/t/frontend-timeout-wesentlich-kurzer-als-gc-maxlifetime/55926/10 "2018-11-28T08:20:45Z")

</div>

Wenn ich mir meine Systeminfo (weiter oben im Thread) ansehe steht da bei session.name = SHOPWAREBACKEND. Wird darüber das Timeout im FRONTEND gesteuert?

Sieht für mich eher so aus, wie wenn für die Frontend-Session der Masterwert von 1440 genutzt wird. Das würde der Zeit von 24 Min. entsprechen nach der der automatische Logout im Frontend erfolgt.

---

<div class="post-metadata">

**Author:** ![sbkmp](https://avatars.discourse-cdn.com/v4/letter/s/d26b3c/32.png) [@sbkmp](https://forum.shopware.com/u/sbkmp)\
**Post date:** [30. Mai 2019 um 05:49 UTC](https://forum.shopware.com/t/frontend-timeout-wesentlich-kurzer-als-gc-maxlifetime/55926/11 "2019-05-30T05:49:55Z")

</div>

Hi, gibt es hier schon neue Erkenntnisse? Das ist bei uns aktuell auch so wie beschrieben und wirklich schrecklich!

---

<div class="post-metadata">

**Author:** ![wolfgang007](https://avatars.discourse-cdn.com/v4/letter/w/958977/32.png) [@wolfgang007](https://forum.shopware.com/u/wolfgang007)\
**Post date:** [2. Oktober 2019 um 10:04 UTC](https://forum.shopware.com/t/frontend-timeout-wesentlich-kurzer-als-gc-maxlifetime/55926/12 "2019-10-02T10:04:39Z")

</div>

Mir scheint es auch so, also ob der MasterWert 1440 bei&nbsp;gc\_maxlifetime genutzt wird und nicht der Local Value…

---

<div class="post-metadata">

**Author:** ![sunflower](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.shopware.com/sunflower/32/8100_2.png) [@sunflower](https://forum.shopware.com/u/sunflower)\
**Post date:** [17. Oktober 2019 um 12:45 UTC](https://forum.shopware.com/t/frontend-timeout-wesentlich-kurzer-als-gc-maxlifetime/55926/13 "2019-10-17T12:45:39Z")

</div>

Das sollte eigentlich ab 5.5.5 behoben sein.

[https://issues.shopware.com/issues/SW-22825?\_ga=2.118987916.489439691.1571232449-525643484.1532518820](https://issues.shopware.com/issues/SW-22825?_ga=2.118987916.489439691.1571232449-525643484.1532518820)

Mein Problem seinerzeit wurde in der 5.4.6 durch den oben von Moritz genannten Patch behoben.  
Zumindestens hat der Kunde sich seither nicht mehr beklagt und ein Update von Shopware gab es bis heute dort nicht. ![Wink](https://europe1.discourse-cdn.com/flex013/uploads/shopware/original/1X/b3785da0cbf2c8566cb535dcf55b2730b5224899.png "Wink")
