Hi,
We have a few sites running 4.5 and we noticed that the scheduled task cleaning old sessions (core\task\session_cleanup_task) doesn't seem to clean anything in the mdl_sessions table.
After awhile, the task fails. Ths only report I found about this is the following: https://stackoverflow.com/questions/79272421/moodle-cleanup-old-sessions-cron-task-failing. Nobody answered.
Any ideas? Did we miss some basic settings in 4.5?
François
Is there a reason to use DB for sessions? Lot's of IO when one sets a moodle that way. Have always thought it best to use files in moodledata/sessions/
You could add a line to config.php
$CFG->dbsessions='0';
which then forces sessions to files and your moodledata/sessions/ directory will show small files like:
sess_3dnehq7afhjsgahnag141pvch4
All them begin with sess_ and then random other.
'SoS', Ken
"Obviously. I just deleted all the table content and lost my session."
Truncate the table ... means remove all rows - table remains but no data in table.
Yes, if your session was in DB and you truncated rows, you would loose the current session. Can you log back in?
I see in your table the time stamps for timecreated and timemodified are exactly the same ... which would be true if your server using DB for sessions. That's an epoch time stamp ... user an epoch time stamp converter on the web to see in humanly understandable terms. That number looks like today?
Your screen shot cut off the comment ... here's what it said:
"If enabled, this setting will use the database to store information about current sessions. Note that changing this setting now will log out all current users (including you). If you are using MySQL please make sure that 'max_allowed_packet' in my.cnf (or my.ini) is at least 4M. Other session drivers can be configured directly in config.php, see config-dist.php for more information. This option disappears if you specify session driver in config.php file."
So your comment:
"Obviously. I just deleted all the table content and lost my session."
would be true.
Add that line I suggested. A line in config.php file overrides any config setting held in DB. And make sure that moodledata/sessions directory exist and is owned by web service user and is read/write/execute to that user.
'SoS', Ken
My bad ... mis-understood. You are correct. Just looked at that table for a sandbox 4.5.1 site and indeed that table is populated ... even by bots. Many of the IP addresses I saw in that table, I have in my drop zone!
You might want to consider installing logwatch ... and send daily report to a user on the moodle server itself ... never leaves server.
There is a section of that daily report that shows web errors. I use that to search web server logs to find the IP addresses that are probing too much and put those IP's (or a range of IP's from that network) in drop zone.
If that table isn't cleaned up ... can see it will get VERY large.
Checked a 4.1, a 4.2, a 4.3, and a 4.4. All of those versions do clean up that table. Appears to be an issue with 4.5.
Until that's added/fixed, truncate the table!
'SoS', Ken
