Plesk 10.4.4 MU#16 broke old PHP session file removal

[breun]

We noticed that some time in February 2012 our Plesk 10 servers stopped removing old session files, which caused the /var/lib/php/session directories on our servers to fill up with millions of session files that should have been removed automatically.

We noticed the following change in Plesk 10.4.4 MU#16:

----
[-] Fix of permissions on folder defined in session.save_path of php.ini.
----

The default permissions, owner and group for /var/lib/php/session are 0770 (drwxrwx---) root:apache, but Plesk 10.4.4 MU#16 changed this to 1733 (drwx-wx-wt) root:root. Since this change PHP has stopped removing old session files.

We have reported this issue to Parallels and for now we have reverted the permission and group change on /var/lib/php/session on our Plesk 10.4.4 servers to 0770 (drwxrwx---) root:apache.

[faris]

Thanks for the heads-up.

[madadam]

Has there been any resolution / feedback from Parallels? Every time the server auto-applies a patch the ownership is reverted to root:root and PHP session cleanup fails!

[scott]

Is there a log that would indicate that this happened? We could write a self healing rule to automatically fix it.

[paulie]

Hi,

/root/.autoinstaller/microupdates.xml would show a different modify time, and the counter inside it would increment (so an md5sum might be a safer check).

Microupdates are great in that it allows Parallels to actually respond to issues in a timely fashion, but its ridiculous that all previous Microupdates are reapplied whenever a new comes out. We have a problem with this as a certain MU in 9.5.4 overwrites the proftpd binary that we install through yourselves.

Took us quite a while to work that one out!

Paul

[breun]

Has there been any resolution / feedback from Parallels? Every time the server auto-applies a patch the ownership is reverted to root:root and PHP session cleanup fails!

Parallels said they fixed in MU#22, but our servers were on MU#26 already when we first noticed this issue, so I guess that fix didn't work. At least not on our servers. Indeed the ownership and permissions still got altered after MU#26. I'll contact Parallels again to report this is still an issue.

Is there a log that would indicate that this happened?

I haven't found any log entries for this condition, PHP session garbage collection seems to fail silently.

[breun]

We have a problem with this as a certain MU in 9.5.4 overwrites the proftpd binary that we install through yourselves.

Took us quite a while to work that one out!

The same happens with Plesk 10.4.4. ASL contains a self-healing rule for this condition which will reinstall the psa-proftpd package if it detects that Plesk overwrote the binary. But if you're not running ASL, then yes, you will have to know about this.

[faris]

I finally found time to look at our systems.

/var/lib/php/session is root.root and wrong permissions on all of them - just as Breun is seeing. Loads of files going back to when Plesk was installed on these servers.

Scott/Mike -- a self-healing rule for this would be very nice, I think! Please?

[breun]

I also recommend contacting Parallels to put some pressure on them to fix it. We've contacted them a couple of times about this now, but if more people start reporting this they might do something about this sooner.

Until now we've just been changing back the group and permissions after every micro update.

[faris]

OK. I'll file a bug report. And maybe use the PPE forum too?

Will these old session files get auto-deleted now that I've fixed the permissions, or do I need to delete them manually?

There are so many that whatever is going to delete them is going to fall over if I'm unlucky.

I'm also curious as to what happens with php-FastCGI sessions -- they can't be written here. the FastCGI default site-specific php.ini seems to imply cookies get used, but I'm not certain I'm reading the config correctly.

[breun]

Will these old session files get auto-deleted now that I've fixed the permissions, or do I need to delete them manually?

There are so many that whatever is going to delete them is going to fall over if I'm unlucky.

The probability that session garbage collection is run on session initialization is session.gc_probability/session.gc_divisor, which is 1/1000 by default (see /etc/php.ini for these settings and the comments which explain how this works). One unlucky session initialization might indeed take a long time if you have lots of old sessions around.

The default session.gc_maxlifetime is 1440 seconds (24 minutes). If you don't use a custom session.gc_maxlifetime I'd recommend manually removing all session files which are older than a day for instance (something more than session.gc_maxlifetime anyway), and leaving the rest to the PHP garbage collection:

Code: Select all

find /var/lib/php/session -mtime +1 -delete

[faris]

Thanks Breun!

[faris]

This post (and some of those that follow it) is interesting: http://forum.parallels.com/showpost.php ... ostcount=5

This relates to Plesk 11, however.

[scott]

Is there a log event that captures when this occurs?

[faris]

No event, no.

But can't the daily ASL housekeeping script trigger a check on the perms/ownership on that dir and change if need be?