We have an Opensuse 11.0 server running Apache, PHP and MySQL. We have several little gadget applications written in PHP that access that SQL database.
The PHP session files on my Opensuse 11.0/Apache server are created in /var/lib/php5. Something keeps changing the permssions on that folder (when the server is restarted?). The symptom is obvious: when we browse to one of our app pages, we get startup errors; the logs show “unable to create/access session file(s).” I’ll go in with SSH and sure enough, /var/lib/php5 will have changed to root/root ownership/group. I’ll change it back to apache/apache and everything will be fine.
Any ideas? What could be changing the ownership on that directory without my knowledge? I’ve done a quick grep through /etc and I’ve glanced at the cron jobs, but didn’t see anything obvious.
On my SLES 11 system I have wwwrun:root as the owners despite a few
reboots. I would suggest finding out what could possibly modify that on
your system… if you’ve setup any cron jobs, disable them for now. Any
startup scripts? Check them out too. You could potentially enable
filesystem auditing as well to see if it will catch the userid making the
change.
Good luck.
smpoole7 wrote:
> We have an Opensuse 11.0 server running Apache, PHP and MySQL. We have
> several little gadget applications written in PHP that access that SQL
> database.
>
> The PHP session files on my Opensuse 11.0/Apache server are created in
> /var/lib/php5. Something keeps changing the permssions on that folder
> (when the server is restarted?). The symptom is obvious: when we browse
> to one of our app pages, we get startup errors; the logs show “unable to
> create/access session file(s).” I’ll go in with SSH and sure enough,
> /var/lib/php5 will have changed to root/root ownership/group. I’ll
> change it back to apache/apache and everything will be fine.
>
> Any ideas? What could be changing the ownership on that directory
> without my knowledge? I’ve done a quick grep through /etc and I’ve
> glanced at the cron jobs, but didn’t see anything obvious.
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
The only cron job is a simple rsync that does a nightly backup. As I mentioned above (but without details), I’ve looked through /etc/php5, etc/apache2 and at the startup scripts in init.d and haven’t found anything obvious.
I was hoping that someone here had experienced this and knew where a stray “chown” might have buried itself. Since it seems to be happening at reboot, I’m concentrating on boot and init scripts.
If it reliably happens on reboot does it also reliably happen on restart
of apache2? PHP doesn’t, afaik, have any scripts of its own that would be
involved.
Good luck.
smpoole7 wrote:
> ab@novell.com;1968993 Wrote:
>> On my SLES 11 system I have wwwrun:root as the owners despite a few
>> reboots. I would suggest finding out what could possibly modify that
>> on your system… if you’ve setup any cron jobs, disable them for now.
>
> The only cron job is a simple rsync that does a nightly backup. As I
> mentioned above (but without details), I’ve looked through /etc/php5,
> etc/apache2 and at the startup scripts in init.d and haven’t found
> anything obvious.
>
> I was hoping that someone here had experienced this and knew where a
> stray “chown” might have buried itself. Since it seems to be happening
> at reboot, I’m concentrating on boot and init scripts.
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
Reboot this time didn’t do it, restart of Apache2 didn’t do it … but here’s a clue: we’re set up for automatic updates. The logs show that a PHP update was installed on 04-05. The problem appeared this morning. That may have been the cause.
smpoole7 wrote:
> ab@novell.com;1969015 Wrote:
>> If it reliably happens on reboot does it also reliably happen on restart
>> of apache2? PHP doesn’t, afaik, have any scripts of its own that would
>> be involved.
>
> Reboot this time didn’t do it, restart of Apache2 didn’t do it … but
> here’s a clue: we’re set up for automatic updates. The logs show that a
> PHP update was installed on 04-05. The problem appeared this morning.
> That may have been the cause.
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
www:~ # rpm -V php5
S.5....T c /etc/php5/cli/php.ini
.M...UG. /var/lib/php5
I solved my problem for now by simply inserting a cron job that resets ownership of /var/lib/php5 every morning at 1AM. Clunky and ugly, but it does the trick.
Hmmm… well at least we know it’s not the RPM (or at least not the
files/directories as stored in the RPM) but that doesn’t help us find what
is causing this, really. Oh well… I guess you can go from there but if
you find the root of the problem please let us know.
Good luck.
smpoole7 wrote:
> Heh, heh! Well, look at that:
>
>
> Code:
> --------------------
>
> www:~ # rpm -V php5
> S.5…T c /etc/php5/cli/php.ini
> .M…UG. /var/lib/php5
>
> --------------------
>
>
> I solved my problem for now by simply inserting a cron job that resets
> ownership of /var/lib/php5 every morning at 1AM. Clunky and ugly, but it
> does the trick.
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
Yes, /etc/permissions stores some permissions, but I don’t think those are
changed with every load or even affect those systems. Also I don’t see
/var/lib/ntp in any of those files so probably not related to those.
Your post reminded me of the line from Mrs. Doubtfire… “…it was a
drive-by fruiting…”
Good luck.
FeatherMonkey wrote:
> Is it not in /etc/permission perhaps (Shrug) seems to be doing something
> with ownership.
>
> Though I would of thought grep would of found it. Either way is not
> permissions the elegant way of solving(Shrug).
>
> Just a random drive by posting, thinking aloud really.
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
I’ll admit I’m not an expert on rpm at the CLI. I much prefer Yast because it takes care of the gnarly details for me, and I have more important things to worry about.
But from looking at the man page, “rpm -V” means “verify” – i.e., compare the current state of the package files to those stored in the RPM. The response for “/var/lib/php5” specified “M, U and G” as different – mode, user and group. I think I did tinker with chmod while I was experimenting, so that explains the “M.”
Remember, I have changed the ownership and group on that directory to “apache.apache.” It was originally “root.root” right after the update. This tells me that the update IS the cause. It’s setting the permissions on that folder each time I update.
I’ve gone back through the logs, and the last time this problem appeared (that’s as far as my logs go), it was right after an update. So … I think this HAS been solved, at least to my satisfaction.
The more you add, points to permissions, permissions is run with Suseconfig which is run after update.
Me I would look into the permissions, I’m sure its related to this. But as said I’m presuming permissions is a fail-safe to check priority files for the correct permissions and changes them.
Otherwise I haven’t got a clue what permissions does.
I see… so you ran it when it was “right” according to you and wrong per
the RPM… I was under the mistaken impression you ran it when it was
still root:root so thank-you for clarifying that. Well that’s
interesting. Perhaps report a bug against the package, or else try SLES
11 which seems to be working for me so far.
Good luck.
smpoole7 wrote:
> ab@novell.com;1969516 Wrote:
>> Hmmm… well at least we know it’s not the RPM (or at least not the
>> files/directories as stored in the RPM)
>
> Well, wait a minute. I think it HAS been solved.
>
> I’ll admit I’m not an expert on rpm at the CLI. I much prefer Yast
> because it takes care of the gnarly details for me, and I have more
> important things to worry about.
>
> But from looking at the man page, “rpm -V” means “verify” – i.e.,
> compare the current state of the package files to those stored in the
> RPM. The response for “/var/lib/php5” specified “M, U and G” as
> different – mode, user and group. I think I did tinker with chmod while
> I was experimenting, so that explains the “M.”
>
> Remember, I have changed the ownership and group on that directory to
> “apache.apache.” It was originally “root.root” right after the update.
> This tells me that the update IS the cause. It’s setting the
> permissions on that folder each time I update.
>
> I’ve gone back through the logs, and the last time this problem
> appeared (that’s as far as my logs go), it was right after an update. So
> … I think this HAS been solved, at least to my satisfaction.
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
