I have been running SuiteCRM for a couple of years as a proof-of-concept for our sales team. It has recently seen much more usage and starting to look like something that is worth purchasing the paid version of. However, last week users were reporting to me that when they tried to login, they would get something like ‘login session expired’.
I tried to update UCS from UCS 4.4-8 to UCS 5.0-6 via the management page, but nothing would happen. So when I SSH into the server and tried via console, I would get errors saying not enough space to create temp files.
it is on a VM running Ubuntu, on a 200GB vdisk. So I ran df -h and got
Showing the two docker overlay2 hogging all of the index nodes. I am not well versed on SuiteCRM and I have done a lot of research looking at how to clean these docker containers, but I have been unsuccessful. There is a lot of data and custom modules that I would really like to be able to save. I am hoping someone may be able to point me in the right direction.
Once corrected, would it be beneficial to upgrade UCS? What proactive measures can I take to avoid this in the future?
I pulled up my php.ini located in /etc/php/7.0/apache2/
However, any line that has the sessions.save_path config is commented out. This CRM was the default SuiteCRM Ubuntu VM image I pulled off of the site. I can’t say I modified much of it from the default.
I would assume the default location would be a tmp folder of some kind, I checked /var/lib/php, but I only have a modules folder in that directory, no sessions folder.
Trying to prune docker doesn’t reclaim any space. Which an abundance of PHP sessions makes sense. I am just at a loss as to how to locate and/or remove these sessions. Alos, if there is a way to prevent this from happening again.
The tip from Chris should solve your problem, but anyway let me just say the generic answer is to get the effective session.save_path value from phpinfo
For CLI, that is as simple as typing
php -i | grep save_path
For the web server, you can go in Admin / Diagnostics and get a phpinfo output. Or create a simple phpinfo file in your server (many tutorials online will teach you this).
Another option would be to go inside the container and run a series of df -i, drilling down to the exact directory.
I am sorry if my inexperience is showing. While I have used Docker a lot in the past, I have never really done much other than run pre-built containers and never really modified or played around with the inner-workings.
Locating the PHP sessions has be a bit stumped.
root@crm:~# php -i | grep save_path
session.save_path => /var/lib/php/sessions => /var/lib/php/sessions
root@crm:~# cd /var/lib/php/sessions
-bash: cd: /var/lib/php/sessions: No such file or directory
df -i still shows the 2 docker overlays at 100% IUse.
You can also use a depth of 2 if you find it heplful
The idea is for you to drill down. See which directory has the most inodes, go into it, see what is underneath that in terms of inodes. Eventually you will get there.
About the value defined in php.ini, maybe you got that from outside the container, not from the inside?
Thank you to everyones help here, I was able to clean up the sessions folder. I didn’t realize there was a similar root directory within the docker overlay, THAT was where my PHP sessions directory was. After cleaning that up,
Which I don’t quite understand why, I can login to Univention Portal no problem, is that because SuiteCRM is running in a Docker container?
Needless to say, I was pretty bummed out when I came in this morning seeing that I had successfully freed the majority of inodes, only to realize users are still unable to login. Which is odd because when I went in and deleted a bunch of log files, freeing up ~1% of inodes, I was able to login once, another user was able to login once, then it was back to the session has expired.
Even though the inodes are free, I am still showing an insane amount of sessions in the sessions directory still.
It doesn’t look like you cleaned up the directory yet…
I get the feeling that you’re working blind-folded
Now that you found out the container, and the directory, can’t you just go in there with normal cd command and check what’s there, and delete what is not needed?
Start a bash session within the container, and cd into the sessions directory.
