Jump to content

Session problems resulting in 500 error


Peter Knight
 Share

Recommended Posts

I have a demo site which I moved to a new VPS for client testing

We noticed that leaving a page open and then revisiting the site can result in a 25 second(ish) to load time and will then throw a 500 Error.

The hosting guys had a look and confirmed that the server is fine but the issue could be related to authentication or sessions.

We are running Page Protector and ProCache so I wondered if there were any known bugs here and any recommended actions.

My actual PW log doesn't show anything but the server log has plenty of these

 

2018-12-06 08:14:00 Error xxx.141.1x.101 500 POST /who-we-are/ HTTP/1.0     1.58 K Apache access
2018-12-06 08:14:45 Warning xxx.141.1x.131   mod_fcgid: read data timeout in 45 seconds, referer: http://demo.abc.not/who-we-are/       Apache error
2018-12-06 08:14:45 Error xxx.141.1x.131   End of script output before headers: index.php, referer: http://demo.abc.not/who-we-are/       Apache error
2018-12-06 09:03:18 Error xxx.141.1x.131   2614#0: *667 recv() failed (104: Connection reset by peer) while reading response header from upstream       nginx error

Thanks

P

Link to comment
Share on other sites

Looks like the server is using nginx as an apache proxy. I have had a couple of PW sites on these setups and decided never again ? I could never figure out what the problem was and as soon as I moved to a regular apache system everything worked as expected. Maybe someone else out there solved it and can provide a solution.

Link to comment
Share on other sites

I appreciate it could be a lot of things.

3 hours ago, dragan said:
  • What mySQL version do you use?
  • Do you use DB- or file-based sessions?
  • Do you use https at all?

I've seen a few other PW threads that had similar error messages... could be plenty of stuff involved o_O

1. I'm using 5.5.60
2. Not sure
3. Not yet but we will be when the site goes live

I think what's happening here is as follows.

1. Client logs in via page protector to their site
2. While browsing the site they leave a tab open and go into meetings etc
3. They come back 15 mins later and their session has expired
4. They try to browse the site but as their session has expired, they get a spinning / loading thing

 

Does that sound like a plausible explanation? And if so, is there a way to extend someone's Processwire session cookie for an hour or so?

P

 

Link to comment
Share on other sites

Your mySQL version is fairly recent; I don't think that has anything to do with your problems.

if you have Tracy Debugger installed, you can var_dump($config), then search for anything session-related.

You can adjust session lifetime in site/config.php (my sessionExpireSeconds is set to 86400 seconds = 24 hours = default)
https://processwire.com/api/ref/config/#pwapi-methods-session

The SessionHandlerDB module is in the core since some time: https://processwire.com/blog/posts/pw-3.0.103/#new-feature-in-session-database-core-module

 

Link to comment
Share on other sites

36 minutes ago, Peter Knight said:

They try to browse the site but as their session has expired, they get a spinning / loading thing

Do you mean browse on frontend, or try to access page editing in the backend? The backend issue is normal PW behavior when a session has expire. I guess because you are using Page Protector it's causing the same issue on the frontend.

Perhaps the login persist module might help: http://modules.processwire.com/modules/login-persist/

 

Link to comment
Share on other sites

13 minutes ago, dragan said:

Your mySQL version is fairly recent; I don't think that has anything to do with your problems.

if you have Tracy Debugger installed, you can var_dump($config), then search for anything session-related.

You can adjust session lifetime in site/config.php (my sessionExpireSeconds is set to 86400 seconds = 24 hours = default)
https://processwire.com/api/ref/config/#pwapi-methods-session

The SessionHandlerDB module is in the core since some time: https://processwire.com/blog/posts/pw-3.0.103/#new-feature-in-session-database-core-module

 

Thanks. 

I've added the sessionExpireSeconds to my config. There was nothing in place regarding this previously.

I also enabled the Module Session Handler Database and had a PHP warning within processwire as follows

Quote

 Your PHP has a configuration error with regard to sessions. It is configured to never clean up old... 28 secs 

Your PHP has a configuration error with regard to sessions. It is configured to never clean up old session files. Please correct this by adding the following to your /site/config.php file: ini_set('session.gc_probability', 1);

I'm going to add that ini_set and hope it helps.

Link to comment
Share on other sites

7 minutes ago, adrian said:

Do you mean browse on frontend, or try to access page editing in the backend? The backend issue is normal PW behavior when a session has expire. I guess because you are using Page Protector it's causing the same issue on the frontend.

Perhaps the login persist module might help: http://modules.processwire.com/modules/login-persist/

 

They are often logged into the site under PageProtector to view the front end AND  logged in via /processwire/ too.

Isn't there a way that a user can be kicked back into the pageprotector login screen if their session has expired?

 

Link to comment
Share on other sites

You could try something quick and dirty in your template file.

Before any output check if the $user is logged in on every request and redirect him to the same page if not. This should trigger your login I guess

<?php 
if(!$user->isLoggedin()){
 $session->redirect($page->url) 
}
?>

 

Link to comment
Share on other sites

1 hour ago, LuisM said:

You could try something quick and dirty in your template file.

Before any output check if the $user is logged in on every request and redirect him to the same page if not. This should trigger your login I guess


<?php 
if(!$user->isLoggedin()){
 $session->redirect($page->url) 
}
?>

 

That's not a bad idea assuming I remove it before we go live with the site.

I'll just check with @adrian that this is compatible with his page protector ?

Link to comment
Share on other sites

44 minutes ago, Peter Knight said:

That's not a bad idea assuming I remove it before we go live with the site.

I'll just check with @adrian that this is compatible with his page protector ?

That's basically what is going on with Page Protector already so I don't see how it will help.

If they reload the page and it churns for 30 seconds then I think there is something else going on. There are mod_fcgid settings that can be tweaked but as I mentioned above I tried for ages and never got anywhere. I think there is something between PW and nginx as a proxy for apache, but I couldn't figure out what it was. All the issues i had (which sound similar to yours) went away when I changed to a pure apache server (not FastCGI). Maybe others have been down this road and got things working. BTW - I didn't have PageProtector enabled and still had issues.

 

Link to comment
Share on other sites

10 minutes ago, adrian said:

That's basically what is going on with Page Protector already so I don't see how it will help.

If they reload the page and it churns for 30 seconds then I think there is something else going on. There are mod_fcgid settings that can be tweaked but as I mentioned above I tried for ages and never got anywhere. I think there is something between PW and nginx as a proxy for apache, but I couldn't figure out what it was. All the issues i had (which sound similar to yours) went away when I changed to a pure apache server (not FastCGI). Maybe others have been down this road and got things working. BTW - I didn't have PageProtector enabled and still had issues.

 

Good to know - thanks.

Do you mean choose option 2 below?

  • FastCGI application served by Apache
  • FPM application served by Apache
  • FPM application served by nginx
Link to comment
Share on other sites

18 minutes ago, Peter Knight said:

Good to know - thanks.

Do you mean choose option 2 below?

  • FastCGI application served by Apache
  • FPM application served by Apache
  • FPM application served by nginx

I'd certainly give that option a go. I am not super au fait with these managed server setups - I mostly used dedicated servers or unmanaged VPS setup, but with my limited experience, I have found that FastCGI (which uses nginx) to be a problem with PW. That said I haven't seen that much about it on these forums (https://processwire.com/talk/topic/19405-502-bad-gateway-after-24-hours-live/) so maybe it was just me ? and maybe it's not the same issue you are seeing - just guessing really.

 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...