Atomicorp

Errr....so, having installed MU#40 for Plesk 10.4.4 a few days ago and having updated php at the same time on a particular system, I received a call from a customer who is using php-fastcgi to say that there were errors relating to saving session files in his website logs.

To my amazement, I found /var/lib/php/sessions to be root.apache drwxrwx--- just as it should be.

What's more, I never got round to fixing the ownership and permissions on this particular system.

So SOMETHING has automagically fixed the ownership and permissions issue.

But it doesn't explain why the customer is seeing session write errors. I thought this was dealt with autmagically by Plesk when php-fastcgi was used. Ah well. One thing fixed, another broken

QUICK UPDATE: It must be ASL - Scott/Mike have added something without telling us? I've checked 4 systems. 3 ASL ones have correct ownership/perms. One non-ASL one has wrong perms/ownership.

Yeah theres a simple event for it right now, but if something changes it again theres no detection for that yet. What we need to find is some kind of log thats going to see it happen so it would be fixed with a SH rule more reliably.

I think we just need to keep bugging Parallels about this so they stop messing with that directory's group and permissions: bugreport@parallels.com

It seems this has been fixed in Plesk 10.4.4 MU#41: http://kb.parallels.com/en/114503

[-] PHP garbage collector can't delete session because of lack of permissions on folder defined in session.save_path directive (114368, 109394)

In current Plesk 9, 10 and 11 versions this problem is fixed AFAIK. The latest micro updates at least didn't change /var/lib/php/session and it's still set to mode 0770, user root, group apache for us.