Has anyone had any problems with multiple users logged in at the same time. I am finding that when more than one of my students is logged in at the same time, sometimes they are switched. I talked with our server support staff and they are claiming that it is how PHP handles sessions and that the problem lies with the session management of PHP.
Does MOODLE use the session management within PHP?
Any ideas of what might be causing users to be switched when logged in at the same time? I only have about 45 students currently using MOODLE.
Thanks much for any help.
Kirsten,
Could you provide a little more information on your problem, what kind of configuration Moodle is running on and the type of authentication your sysadmin has set up?
Thank you everyone for all your responses. I figured it had to be something with the way in which my server (system) is setup since Moodle is used successfully on many different sites with many more users than I have.
I have asked my server support staff about the configuration of the proxy server and what is being saved. Here is a little more information on the system:
Apache 2
PHP 4.3.3
Moodle 1.3.3
I have had this problem randomly though since last March when it was initially setup. In the meantime we have upgraded Apache, PHP and Moodle - thus, I don't it is a problem with the software.
The server system that Moodle is running on uses a cluster system with 2 nodes. The cluster then decides which node is best to process the requests. My guess is that the problem lies here...
Anyhow, I will continue working on this. Any ideas are always appreciated. Anyhow else use a cluster server system?
Thanks again. Cheers.
I have asked my server support staff about the configuration of the proxy server and what is being saved. Here is a little more information on the system:
Apache 2
PHP 4.3.3
Moodle 1.3.3
I have had this problem randomly though since last March when it was initially setup. In the meantime we have upgraded Apache, PHP and Moodle - thus, I don't it is a problem with the software.
The server system that Moodle is running on uses a cluster system with 2 nodes. The cluster then decides which node is best to process the requests. My guess is that the problem lies here...
Anyhow, I will continue working on this. Any ideas are always appreciated. Anyhow else use a cluster server system?
Thanks again. Cheers.
Well, the saga continues.... We switched the Moodle software off the "cluster server system" yesterday, but even this morning, there was a user who was switched with another. Ugh! This is causing havoc.
After more discussions with our server admin staff, it turns out we are using a proxy server and perhaps by removing this proxy server this will help. However, I just read this discussion thread:
http://moodle.org/mod/forum/discuss.php?d=10941
Has anyone tried changing the location where Moodle stores the sessions. A suggestion was made to have Moodle store the PHP sessions in the default PHP session directory. Is this possible? What modifications should be made and where?
Thanks for your help.
kirsten
Kirsten,
No too sure what you mean? 
I have been using Moodle in my computer classes for over a year and have routinely had 20-30 students logged in and on the same course at the same time without any problems?
I have also logged myself in on multiple machines as the same user and still no problems.
Jeff
Yes, Moodle uses the session management in PHP. I would first suspect a badly configured proxy server (one that would be caching traffic from all the students, including cookies, which is bad). Failing that, you might be using an old version of PHP. I would definitely upgrade to PHP 4.3.8.
Is it possible to change the location of where Moodle saves the sessions? I don't want to change the whole dataroot directory, but only where Moodle saves the sessions.
Thanks.
Thanks.
Moodle/PHP already saves them in a private directory in dataroot ... I can't see that being a problem.
Thanks Martin. The reason that I am asking is that I have been monitoring the sessions directory to see what session files are created and deleted. What I think is happening (which I could very well be wrong!) is that session files are created but are not being deleted properly. And thus, with the left over session files someplace things are getting confused and switching users (sessions).
So, one thought was maybe since the location where Moodle saves sessions is different from the default PHP directory to save sessions, that PHP is having a problem deleting the sessions. We were going to test it by having Moodle saves the sessions in the default PHP directory (session.save_path). Does this make sense?
Where in the code would I make this modification?
Am I barking up the wrong tree?
And of course, thanks much for your help!
We are still troubleshooting this problem. The most recent change was that I made a mofidication to the sessiontimeout in the config - changed it to timeout at 30 minutes. Before it was set at 2 hours. However, session files were being saved in the sessions directory that were 24 hours long still.
Has anyone else monitored the sessions directory and noticed that sessions files have accumulated without being deleted?
Sorry to be bothersome, but I'll post this question again, where in the code would you change were the sessions are being saved? I'd like to test out the session management by having Moodle save the sessions instead in the default PHP session directory.
Thanks for your help.
Has anyone else monitored the sessions directory and noticed that sessions files have accumulated without being deleted?
Sorry to be bothersome, but I'll post this question again, where in the code would you change were the sessions are being saved? I'd like to test out the session management by having Moodle save the sessions instead in the default PHP session directory.
Thanks for your help.
Look in lib/setup.php for the sessionpath stuff.
Thank you very much!
Hi Martin!
How would that help to correct the problem?
WP1
How would that help to correct the problem?
WP1
Hi Kirsten!
I once was not able to enter into my website because there were so many session files I ran out of disk space. I got a message at the bottom of the site [which sorry I did not retain] pointing to sessions as the culprit.
When I entered into the sessions folder for that side, there were a massive amount of session files. I just removed them all and the problem went away. I was able to enter into the website.
Now I periodically check and remove files. They do not go away by themselves. I was going to post in detail about it eventually but then I saw this thread.
WP1
I once was not able to enter into my website because there were so many session files I ran out of disk space. I got a message at the bottom of the site [which sorry I did not retain] pointing to sessions as the culprit.
When I entered into the sessions folder for that side, there were a massive amount of session files. I just removed them all and the problem went away. I was able to enter into the website.
Now I periodically check and remove files. They do not go away by themselves. I was going to post in detail about it eventually but then I saw this thread.
WP1
Thanks WP1 for your message. I am thinking that my problem with the sessions sometimes switching between users logged in simultaneously is related to the accumulation of sessions files in the dataroot/sessions directory.
I have switched the sessions directly from the private dataroot/sessions directory to the PHP default directory specified in the php.ini. However, the session files are still accumulating. Mmmm...
Has anyone tried setting the PHP flag session.use_only_cookies = on? My understanding of this is that the session info is then stored only in the user's browser's cookies files. The sessions files then would not be written on the server (and thus not accumulate). Would this cause any problems within Moodle?
I have switched the sessions directly from the private dataroot/sessions directory to the PHP default directory specified in the php.ini. However, the session files are still accumulating. Mmmm...
Has anyone tried setting the PHP flag session.use_only_cookies = on? My understanding of this is that the session info is then stored only in the user's browser's cookies files. The sessions files then would not be written on the server (and thus not accumulate). Would this cause any problems within Moodle?
I have been testing out Moodle with the PHP flag session.use_only_cookies = on. I was hoping this may resolve the session-switching problem that I have experienced.
Unfortunately, I am very hesitant to make this PHP setting change because Moodle seems to have trouble depending on how the user has their browser preferences set. (This would I expect be the case for any software and not just Moodle.) For example, if I set IE to prompt before every cookie request - Moodle runs very very slow at start-up (it is trying to save the session info in the cookie but cannot do so until I okay the cookie). However, it I added to the browser settings to accept all cookies from the domain where moodle is hosted from - it will be okay. There are too many little nuisances like that where I feel this solution would just cause too many problems.
If anyone has any experience with PHP session management - I'm always open to suggestions as to why the session may switch. Thanks!
I've just seen this thread...
We copied /etc/cron.d/php4 and made it do the same thing for where moodle's sessions live, that solved the problem of old sessions accumulating.
We copied /etc/cron.d/php4 and made it do the same thing for where moodle's sessions live, that solved the problem of old sessions accumulating.
Hi Penny!
I have had this problem of old sessions accumulating to the point where I have run out of disk space and the site will not allow anyone to login so I really appreciate this fix. I have had to go into the site via FTP and manually remove the sessions.
Now I am a newbie. Could you describe what you did in a way a newbie could understand?
Is there someway this could be fixed in the Moodle update coming later this Month v1.43 or into v1.5?
Will also check to see if a bug was filed about this.
WP1
NOTE
I was not able to find a bug filed about this so I filed one.
Bug #2271
WP1
I have had this problem of old sessions accumulating to the point where I have run out of disk space and the site will not allow anyone to login so I really appreciate this fix. I have had to go into the site via FTP and manually remove the sessions.
Now I am a newbie. Could you describe what you did in a way a newbie could understand?
Is there someway this could be fixed in the Moodle update coming later this Month v1.43 or into v1.5?
Will also check to see if a bug was filed about this.
WP1
NOTE
I was not able to find a bug filed about this so I filed one.
Bug #2271
WP1
Hi WP,
Basically, PHP has this garbage collection thing for sessions where there's a cronjob that runs twice an hour that deletes old sessions. The problem here is that moodle's sessions live outside the PHP session place so we had to make a new cronjob that deleted them from moodle's session directory.
The problem here is that if you're deleting sessions, you need the cronbab to run as root or the webserver.
If you're running moodle's cron, either you have the ability to run it as the webserver, or you're running it with wget, which will mean that it's running as the webserver.
If have the ability to run things as the webserver or as root, just make a crontab that contains lines like this:
# /etc/cron.d/php4: crontab fragment for php4
# This purges session files older than X, where X is defined in seconds
# as the largest value of session.gc_maxlifetime from all your php.ini
# files, or 24 minutes if not defined. See /usr/lib/php4/maxlifetime
# Look for and purge old sessions every 30 minutes
09,39 * * * * www-data [ -d /moodledatadir/sessions ] && find /moodledatadir/sessions -type f -cmin +$(/usr/lib/php4/maxlifetime) -print0 | xargs -r -0 rm
Also I don't know how people can do this if they're running windows, which won't have this sort of trickery and magic.
At some point, we can integrate this into moodle's cron, I guess, although we'd have to put in some sort of only run it if it's not windows type behaviour. Martin D will probably have some thoughts on this.
Good luck!
Penny
Basically, PHP has this garbage collection thing for sessions where there's a cronjob that runs twice an hour that deletes old sessions. The problem here is that moodle's sessions live outside the PHP session place so we had to make a new cronjob that deleted them from moodle's session directory.
The problem here is that if you're deleting sessions, you need the cronbab to run as root or the webserver.
If you're running moodle's cron, either you have the ability to run it as the webserver, or you're running it with wget, which will mean that it's running as the webserver.
If have the ability to run things as the webserver or as root, just make a crontab that contains lines like this:
# /etc/cron.d/php4: crontab fragment for php4
# This purges session files older than X, where X is defined in seconds
# as the largest value of session.gc_maxlifetime from all your php.ini
# files, or 24 minutes if not defined. See /usr/lib/php4/maxlifetime
# Look for and purge old sessions every 30 minutes
09,39 * * * * www-data [ -d /moodledatadir/sessions ] && find /moodledatadir/sessions -type f -cmin +$(/usr/lib/php4/maxlifetime) -print0 | xargs -r -0 rm
Also I don't know how people can do this if they're running windows, which won't have this sort of trickery and magic.
At some point, we can integrate this into moodle's cron, I guess, although we'd have to put in some sort of only run it if it's not windows type behaviour. Martin D will probably have some thoughts on this.
Good luck!
Penny
I'm not sure what causes the problem you are seeing, but PHP is definitely cleaning up my Moodle session folders like it should be, automatically.
There should not be a need to run extra clean-up jobs.
There should not be a need to run extra clean-up jobs.
Atbildot uz Martin Dougiamas
Session files are not deleted by cron
Nosūtīja Juan David Martínez Pavony —
Hello all.
I'm running Moodle 1.4.3+ (2004083132), PHP 4.1.2, Debian Linux 3.0 (Woody).
I have been reading a lot about this behavior. I went to PHP bugs site, Debian bugs site, Moodle forums and it does not resolve my problem. Martin and others said, but chmod 777 for sessions directory does not work on my box. Moreover, I set 777 for the session file and directory simultaneously, but nothing. I went to http://mymoodlesite/admin/cron.php, nothing. I set 'display_errors' On in my php.ini file, but nothing. I have been busy 
.
I read about upgrading PHP, but there are related bugs with newer versions. Anyway I have to try them.
I wanted to know if anybody, like Penny Leach I guess, has dealed with this anoying problem. THANK YOU VERY MUCH.
Tip: If anybody got full disk problems because the PHP session files stored on /tmp (default location); notice that /etc/cron.d/php4 file points to /var/lib/php4 directory for PHP session files, so I changed my php.ini file on: session.save_path = /var/lib/php4 (it was /tmp).
The command in /etc/cron.d/php4 file and php.ini session.save_path setting must point to the same location.
Tip: For libmm11 package version 1.1.3-6.2 (stable distribution of Debian, the one I have installed) you must update it to 1.1.3-6.3 to remove the huge file in PHP session files directory (/tmp or /var/lib/php4). It is a Debian bug.
Luck!
Atbildot uz Juan David Martínez Pavony
Re: Session files are not deleted by cron
Nosūtīja Martín Langhoff —
Given that you're on Woody, you are probably not using Jordi's excellent Moodle package (which is on Sarge).
If you take a look at the php.ini supplied by Debian, and otherwise the README.Debian file, you'll see that the default PHP session cleanup is disabled. Instead, there's a cleanup triggered in /etc/cron.d/php4
Make a copy of that file, and edit it so that it also does the cleanup of the moodledata/session/ directory.
We do a lot of Moodle'ing under Debian (sarge) and this is part of our routine...
If you take a look at the php.ini supplied by Debian, and otherwise the README.Debian file, you'll see that the default PHP session cleanup is disabled. Instead, there's a cleanup triggered in /etc/cron.d/php4
Make a copy of that file, and edit it so that it also does the cleanup of the moodledata/session/ directory.
We do a lot of Moodle'ing under Debian (sarge) and this is part of our routine...
Atbildot uz Martín Langhoff
Re: Session files are not deleted by cron
Nosūtīja Juan David Martínez Pavony —
Hi Martin. You are right. I am not using Jordi's (BTW, where is it?) Your suggestion is exactly what I have done: I put an extra line in 'moodle' file on /etc/cron.d
Thank you for your support. I know now this is common in Debian.
That takes me to think if it is time to post one bug report somewhere about it. What do you think is the best place? Debian bugs site?
Best luck!
Hi, I forgot to mention that I am now running PHP 4.3.8 on Apache 1.3.31 and Moodle 1.3. Thanks.
they are claiming that it is how PHP handles sessions and that the problem lies with the session management of PHP.
Tell them to stop making things up and fix the problem.
Do they really expect you to believe that the thousaud or so sites using Moodle (not to mention the thousands of other sites using hundreds of other multiuser php apps that utilize php sessions) are just putting up with having their users randomly switched????
Sorry, I just hate it when incompetants are put in charge of server administration.
BTW, upgrading PHP is generally so easy even server admins can do it
.
Tell them to stop making things up and fix the problem.
Do they really expect you to believe that the thousaud or so sites using Moodle (not to mention the thousands of other sites using hundreds of other multiuser php apps that utilize php sessions) are just putting up with having their users randomly switched????
Sorry, I just hate it when incompetants are put in charge of server administration.
BTW, upgrading PHP is generally so easy even server admins can do it