xusword Posted March 20, 2023 Share Posted March 20, 2023 Hi PHP users We are migrating a PHP website from an old host to a container. The old code runs on VM directly, now we built a container that facilitate the PHP website. Both old and new PHP website run on top of apache httpd with php version 5.4.16. However, there's a feature of this website that saves user session under `/var/lib/php/session` that does not work in our new, containerized version. The directory seems to always be empty even if there are active sessions. We have checked the following: * The `session` configuration seems identical between the old and new site (pasting the config below) * We verified `apache` user is the owner of `/var/lib/php/session` directory * In php error logs, there doesn't seem to be anything indicating why the sessions are not saved I am not familiar with PHP and don't know how I could debug this further, just checking if I can get some help on this. * Any chance we forgot to install any module that would allow session persistent? * Why would there not be any logs indicating the sessions not being saved? Do I need to somehow enable more logging to observe what is happening? * Was the session not saved or did it timeout and get wiped? Is there such setting somewhere that can cause this? Our configuration Session Support: enabled Registered save handlers: files user Registered serializer handlers: php php_binary session.auto_start: Off session.cache_expire: 180 session.cache_limiter: nocache session.cookie_domainno value session.cookie_httponly: Off session.cookie_lifetime: 0 session.cookie_path: / session.cookie_secure: Off session.entropy_file: /dev/urandom session.entropy_length: 32 session.gc_divisor: 1000 session.gc_maxlifetime: 1440 session.gc_probability: 1 session.hash_bits_per_character: 5 session.hash_function: 0 session.name: PHPSESSID session.referer_check: no value session.save_handler: files session.save_path: /var/lib/php/session session.serialize_handler: php session.upload_progress.cleanup: On session.upload_progress.enabled: On session.upload_progress.freq: 1% session.upload_progress.min_freq: 1 session.upload_progress.name: PHP_SESSION_UPLOAD_PROGRESS session.upload_progress.prefix: upload_progress_ session.use_cookies: On session.use_only_cookies: On session.use_trans_sid: 0 Quote Link to comment Share on other sites More sharing options...
ginerjm Posted March 20, 2023 Share Posted March 20, 2023 (edited) I have to ask. What is a "container"? And does 'VM' refer to something I haven't heard of in years when I was working with mainframes? And have you heard that PHP Version 5.x is out of date and could be part of your supposed problem? I may be stupid in asking this but why don't you just let the session be created where your installation wants to put it and not try and 'manage' it? You start it, you save stuff and when your client session is done, PHP will delete it for you. Edited March 20, 2023 by ginerjm Quote Link to comment Share on other sites More sharing options...
requinix Posted March 20, 2023 Share Posted March 20, 2023 9 minutes ago, xusword said: The directory seems to always be empty even if there are active sessions. Does that mean sessions are working and persistent? And you just can't figure out where the data is being stored? Quote Link to comment Share on other sites More sharing options...
xusword Posted March 20, 2023 Author Share Posted March 20, 2023 Thanks @ginerjm, the legacy system run on VM. Virtual machine. The new system run on Docker container. @requinix, I am only guessing but I think PHP created the sub directory `/var/lib/php/session`, because I did not explicitly create that directory and I also know my container won't start properly if apache does not have access to that directory. Httpd will fail with error message complaining lack of access to that directory. What I don't understand is why after it starts it doesn't write anything to that directory. Quote Link to comment Share on other sites More sharing options...
Solution xusword Posted March 20, 2023 Author Solution Share Posted March 20, 2023 Thanks for anyone who replied. Very much appreciated. Turns out our script messed around the permission of `/var/lib/php/session` after having the container run as root it straighten things out Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.