0

I'm struggling with a strange issue that "logs out" users and seems to happen about ten times a day.

The application is an old PHP project. Clients log in; a PHP session is established. Sometimes if a client does nothing for e.g. 2 hours and afterwards sends a new HTTP request, Apache answers with a HTTP 408 error:

1.2.3.4 - - [17/Apr/2020:12:26:30 +0200] "-" 408 3281 "-" "-"

and the user is being sent to the Login page and has to enter their login credentials again, losing their data they have filled in into a form etc. I can't really reproduce the issue, in most cases an idle client can send the next request even 5 hours later and doesn't trigger a 408. It seems pretty random and for all browsers.

I can only reproduce the 408 error if I manually delete the PHP session file on the server. Also strange is that if I do that, I don't see the 408 in Chrome Developer Toolbar, only in the Apache logs.

The Session timeout is high (72 hours). These parameters are configured:

php_value session.gc_maxlifetime 259200
php_value session.gc_divisor 1
php_value session.gc_probability 1
php_value session.cookie_lifetime 0

Now I've read a lot about KeepAlive, but I think that is not the cause as there is not much traffic on the site. And we're talking about hours in between, not seconds.

Is this a common issue and someone can point me in the right direction?

EDIT:

session_unset() is unused in the project. session_destroy is only being called when a user logs out. By deleting the session file in /var/lib/php/sessions the user is logged out of course, hence it redirects to login.php. Seems ok to me. So I think the session file is somehow removed.

I also see this in the error.log:

[Fri Apr 17 22:42:32.386978 2020] [:error] [pid 15563] [client 1.2.3.4:55104] PHP Notice:  session_start(): ps_files_cleanup_dir: opendir(/var/lib/php/sessions) failed: Permission denied (13) in /var/www/myproject/htdocs/sessionReload.php on line 2, referer: https://myproject/page.php

Line 2 in sessionReload.php is:

session_start();
Daniel
  • 3,047
  • 5
  • 22
  • 27
  • There's a firewall between Apache and the clients? – Gerard H. Pille Apr 17 '20 at 18:37
  • I'd start by searching the project for `session_unset()` and `session_destroy()`. There might be a session timeout handling on the application. – Esa Jokinen Apr 17 '20 at 18:47
  • @GerardH.Pille No, I can rule that out. – Daniel Apr 17 '20 at 19:42
  • Let's assume your right. What are the clients' browser and version, OS and version? It looks as if they're opening a connection to the server long before they need it. Would you mind running this on the server: "netstat -tan | awk '{print $NF}' | sort | uniq -c" ? – Gerard H. Pille Apr 17 '20 at 20:12
  • @EsaJokinen Please see the **EDIT** part in the original question – Daniel Apr 17 '20 at 20:52
  • @GerardH.Pille So far I've seen all kinds of Browsers and OS. Win/Mac/Chrome/Firefox/IE. It is mixed and in ~ 98% of the requests, the problem never arises. And if it does, it can be after 1 hour, 5 hours even 10 hours. I can reproduce it with a test machine with only one user. I can't predict when it happens, but eventually it does. – Daniel Apr 17 '20 at 20:55
  • Perhaps you can teach the users to refresh the form before entering it? Add a little javascript that indicates if the session is still valid? Who owns /var/lib/php/sessions and what are the permissions? Owner and permissions of the session files? – Gerard H. Pille Apr 18 '20 at 07:54
  • @GerardH.Pille Yes I thought about that. Maybe Ajax. /var/lib/php/sessions belong to root/root, drwx-wx-wt. The session files in it are owned by www-data. It is a standard install and I haven't changed something there. I think I'm trying to do something with Ajax. Thank you! – Daniel Apr 18 '20 at 10:33
  • 1
    I didn't like the folder's permissions a bit, but they are standard on Debian. Which makes that www-data can't read /var/lib/php/sessions, so garbage collection fails with the above error. I gave www-data a login and tried it, bingo. Debian's ugly solution: disable php garbage collection, let cron do it. I would let the www-data group read that folder. See https://bugs.php.net/bug.php?id=20720&edit=1 . – Gerard H. Pille Apr 18 '20 at 13:47

2 Answers2

0

opendir(/var/lib/php/sessions) failed: Permission denied (13) in /var/www/myproject/htdocs/sessionReload.php

Clearly there is a permissions issue somewhere. You didn't tell us anything about the server this is running on. If sessions are starting then this directory must be writable by something on the webserver (you can check by looking for files/timestamps in this location). That implies that there is more than one uid running PHP (or it could be a rather esoteric issue related to open_basedir, or tis uses the debian php session model and the reaper is in a very different timezone from the webserver).

Check what uids your PHP code is running as / if you are using more than one SAPI. Check the permissions and ownership on the directory and any sub-directories.

If you're still stuck, come back with you found and details of the OS / how PHP is installed.

symcbean
  • 21,009
  • 1
  • 31
  • 52
-2

I had the same issue. I resolved it configuring Apache with a high timeout, an infinite MaxKeepAliveRequests and a KeepAliveTimeout higher than the Timeout.

Pablo L
  • 1
  • No you didn't. Maybe the problem went away at the same time you changed these. They didn't fix the problem. – symcbean Oct 03 '22 at 16:56