Re: Session variable not persisting

"Éric Oliver Paquette" <eopaquette@gmail.com> wrote: > >Le 2013-03-18 à 15:41, Éric Oliver Paquette a écrit : > >> >> Le 2013-03-18 à 15:37, Matijn Woudt a écrit : >> >>> >>> >>> >>> On Mon, Mar 18, 2013 at 8:35 PM, Éric Oliver Paquette ><eopaquette@gmail.com> wrote: >>> >>> Le 2013-03-18 à 15:24, Éric Oliver Paquette a écrit : >>> >>>> >>>> Le 2013-03-18 à 15:20, Matijn Woudt a écrit : >>>> >>>>> >>>>> >>>>> >>>>> On Mon, Mar 18, 2013 at 8:13 PM, Éric Oliver Paquette ><eopaquette@gmail.com> wrote: >>>>> >>>>>> >>>>>> On Mon, Mar 18, 2013 at 7:46 PM, Éric Oliver Paquette ><eopaquette@gmail.com> wrote: >>>>>> Hi all, >>>>>> >>>>>> I'll be swift in my explanation as I can't find in any way the >source of the problem; it seems to be installation-related. >>>>>> >>>>>> At execution, sometimes (randomly it seems at first), variable >session aren't properly stored. >>>>>> >>>>>> >>>>>> In fact, when I run this on my server I randomly have empty >entries in the $_SESSION array. Any thoughts on this? Is this a known >bug (haven't found it…) >>>>>> >>>>>> Thanks! >>>>>> >>>>>> What does phpinfo() show about session stuff? Especially things >like save_handler and cookie_lifetime settings. >>>>> >>>>> Note that this seems to occur 3 times out of 1000 on average. >>>>> >>>>> Now, about your request : >>>>> >>>>> session >>>>> >>>>> Session Support enabled >>>>> Registered save handlers files user >>>>> Registered serializer handlers php php_binary wddx >>>>> >>>>> Directive Local Value Master Value >>>>> session.auto_start Off Off >>>>> session.bug_compat_42 Off Off >>>>> session.bug_compat_warn Off Off >>>>> session.cache_expire 180 180 >>>>> session.cache_limiter nocache nocache >>>>> session.cookie_domain no value no value >>>>> session.cookie_httponly Off Off >>>>> session.cookie_lifetime 0 0 >>>>> session.cookie_path / / >>>>> session.cookie_secure Off Off >>>>> session.entropy_file no value no value >>>>> session.entropy_length 0 0 >>>>> session.gc_divisor 1000 1000 >>>>> session.gc_maxlifetime 1440 1440 >>>>> session.gc_probability 1 1 >>>>> session.hash_bits_per_character 5 5 >>>>> session.hash_function 0 0 >>>>> session.name PHPSESSID PHPSESSID >>>>> session.referer_check no value no value >>>>> session.save_handler files files >>>>> session.save_path /var/lib/php/session /var/lib/php/session >>>>> session.serialize_handler php php >>>>> session.use_cookies On On >>>>> session.use_only_cookies On On >>>>> session.use_trans_sid 0 0 >>>>> >>>>> >>>>> Your settings seem to be fine. My best guess would be hardware >failure, though it seems unlikely. Did you check apache (or whatever >webserver you're using) logs for any errors or warnings? >>>> >>>> Yes I did. Everyhting seems normal there too. >>> >>> Hm… Just noticed something new in fact; was looking a last time >before considering reinstallation on a new server: it seems that the >$_GET['push'] is undefined. In the other scripts I use where I have >this problem, I'm using $_POST variables though but still don't get >stored in $_SESSION. If I'm correct, this may implies that it is apache >that is faulty right? >>> >>> >>> >>> $_GET['push'] will be undefined if you still have your session >stored, but accessing the script directly. It should have nothing to do >with faulty Apache. >> >> Okay, let me paraphrase: when I run the ping pong scripts written up >there, I have a blank in var_dump($_SESSION) if and only if I have >> >> [Mon Mar 18 13:25:37 2013] [error] [client 184.151.114.111] PHP >Notice: Undefined index: push in >/home/www/www.ngenioconnect.com/Modules/MPOSurveyTest/pong.php on line >8 >> >> on apache log. So my question really is, it is apache that handles >the posts and gets requests, as I use both and it seems that the >non-persistence of data occurs before the storage in $_SESSION, is it >possible that it is Apache that is faulty? >Er… I looked where it caused a problem, it seems that $_GET, $_POST and >$_SESSION are indeed all affected. Any clue of a faulty installation >that would cause problem for many surperglobals? It sounds like some kind of memory problem. Can you run a memory tester on that server to see if that's the cause? Thanks, Ash http://www.ashleysheridan.co.uk