Miscellaneous ⇒ Server Chat ⇒ Server Issues with 9.2 (suhosin) (page 4) ⇒ Community Forums ⇒ CPG Dragonfly™ CMS
Forum IndexServer Chat

Server Issues with 9.2 (suhosin) Reply to topic


Thank you, hopefully this thread will help others with the same server issues as I am having to fix theirs.

So I restarted Apache.

So far, nothing is changed for the sessions table.

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
[ Linux / Apache 2.2.8 / MySQL 5.0.45 / PHP 5.2.6 / CPG 8.2b - 9.3.4.1]


Not sure that will resolve the long list of user sessions stuck in the sessions table, but I am hopeful.
....
nothing is changed for the sessions table


So you still having this problem?

.:: I met php the 03 December 2003 :: Unforgettable day! ::.

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
CloudLinux / Apache 2.4 LSAPI / MySQLi 5.7 / PHP 7.3 / head


Yes.

In the who is where block it is not clearing out members or visitors that have long left the site.

And the sessions table doesn't appear to get smaller, just bigger.

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
[ Linux / Apache 2.2.8 / MySQL 5.0.45 / PHP 5.2.6 / CPG 8.2b - 9.3.4.1]


Hmmm, I just went back to the site, and all the threads I'd read and posted in were marked as new, so the issue does seem to be there still.

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
[ Linux / Apache 2.2.8 / MySQL 5.0.45 / PHP 5.2.6 / CPG 8.2b - 9.3.4.1]


So any ideas why the sessions aren't expiring and clearing out?

We can't have it doing this next month ... if there isn't anything else left for me to try, then I will just admit defeat and downgrade the site.

I just need to know before the advertising campaign traffic hits, because it cannot behave that way with double the traffic, we'd lose more folks than we'd gain.

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
[ Linux / Apache 2.2.8 / MySQL 5.0.45 / PHP 5.2.6 / CPG 8.2b - 9.3.4.1]


the following command should return you GTM time, so login using SSH and
date -u

Remember you'll get a GMT time, just make sure its correct.

Also perform the following command and past the results here please.
php -i | grep date

.:: I met php the 03 December 2003 :: Unforgettable day! ::.

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
CloudLinux / Apache 2.4 LSAPI / MySQLi 5.7 / PHP 7.3 / head


date -u got this:
Wed Jul 9 22:00:51 UTC 2008

php -i | grep date got this:
date
date/time support => enabled
date.default_latitude => 31.7667 => 31.7667
date.default_longitude => 35.2333 => 35.2333
date.sunrise_zenith => 90.583333 => 90.583333
date.sunset_zenith => 90.583333 => 90.583333
date.timezone => no value => no value

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
[ Linux / Apache 2.2.8 / MySQL 5.0.45 / PHP 5.2.6 / CPG 8.2b - 9.3.4.1]


Session table must be huge now ... in 2 days i say you should have 2000+ entries, do you?

.:: I met php the 03 December 2003 :: Unforgettable day! ::.

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
CloudLinux / Apache 2.4 LSAPI / MySQLi 5.7 / PHP 7.3 / head


No I clear it out several times a day, or else it would.

It gets to be about 300-500 entries in the sessions tables 3-4 times a day, give or take a few dozen, lol.

We expect our traffic to double or triple in a month though ... soooo it's definitely a concern.

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
[ Linux / Apache 2.2.8 / MySQL 5.0.45 / PHP 5.2.6 / CPG 8.2b - 9.3.4.1]


300-500 it might be a reasonable amount for 2 unknown bots crawling your site, your normal users and few users not accepting cookies.

Table will be cleaned of 5 minutes old records so
1. If the flooding system is enabled and a you really have a bot crawling your site then you will have a top of 150 records (bot crawling at 2 hits/sec)

Try to open includes/classes/session.php scroll at the end of the file and
change gmtime()-300togmtime()-120this way you will have a table cleaned every 2 minutes instead of 5

You may also get the ip addresses flooding your session table search your apache access log files for that ip and let us know the UserAgent. It could be possible that your site is browsed by a BOT not know to us or Its using a different ip that we have on our database.

.:: I met php the 03 December 2003 :: Unforgettable day! ::.

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
CloudLinux / Apache 2.4 LSAPI / MySQLi 5.7 / PHP 7.3 / head


Well, the table is not beng cleared at *all*. As in ever. As far as I can tell, it is not *ever* cleaning out. Or if it is, it's taking hours to do it. Or longer than a day even.

I cleared out the table last night at like 6pm. 7 pm users were shown as being online.

Right now, they are STILL showing as being online. Their sessions were not cleared, and I do not think they would be cleared unless I manually did it as I have been having to do this entire time.

Flooding has been disabled, because it was banning the users and blocking them and myself. Since we could not get that to work properly (ie not disrupting the regular users experience on the site), all flooding and useragent blocking has been disabled.

Hmm my sessions.php did not have gmtime()-300 IN it. Perhaps that is the issue? I will replace that with a current version of sessions.php.

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
[ Linux / Apache 2.2.8 / MySQL 5.0.45 / PHP 5.2.6 / CPG 8.2b - 9.3.4.1]


in session.php you should have a function update_db() could you please copy and past it here.

.:: I met php the 03 December 2003 :: Unforgettable day! ::.

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
CloudLinux / Apache 2.4 LSAPI / MySQLi 5.7 / PHP 7.3 / head


function update_db() { $expired = (gmtime()-($this->sess_time*60)); global $db, $prefix; if (defined('CPG_SHOP')) { // get all expired records from db $result = $db->sql_query('SELECT content FROM '.$prefix.'_sessions WHERE session_time<='.$expired); if ($db->sql_numrows($result) > 0) { // loop through all expired sessions while ($row = $db->sql_fetchrow($result)) { // restock inventory $content = unserialize($row['content']); // loop through items in the order stored in the _shop_sessions table and restock!! foreach($cart AS $item) { // $result = $db->sql_query('UPDATE '.$prefix.'_shop_products SET num_in_stock=num_in_stock+'.intval($item['qty']).' WHERE item_id = '.intval($item['record_number'])); } } } $db->sql_freeresult($result); } // finally update by clearing old records $db->sql_query('DELETE FROM '.$prefix.'_session WHERE time<'.(gmtime()-300)); $this->dbupdate = true; } }

However that is from the sessions.php file that I used to replace the one that was being used before and that I'm thinking was the problem.

And joy of joys - it seems to now be working! YAY!!! I am so glad!

The sessions table looks like it is finally clearing itself out. YAYYYY!

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
[ Linux / Apache 2.2.8 / MySQL 5.0.45 / PHP 5.2.6 / CPG 8.2b - 9.3.4.1]


So have we closed/fixed all issues?

.:: I met php the 03 December 2003 :: Unforgettable day! ::.

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
CloudLinux / Apache 2.4 LSAPI / MySQLi 5.7 / PHP 7.3 / head


I think in regard to the sessions table and the read/not read indicators ... yes.

I am having an issue with the blocks not saving the changes I've made again though. Not sure if it is a server issue or not ... but I'm thinking that it might be better to explore that issue in a separate thread even though it *might* be a server issue.

Let me know if that issue belongs in this thread or not. I've been getting around it by making block changes in phpMyAdmin (lol).

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
[ Linux / Apache 2.2.8 / MySQL 5.0.45 / PHP 5.2.6 / CPG 8.2b - 9.3.4.1]

All times are UTC


Jump to: