Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php

If you can provide more information, feel free to add it
to this bug and change the status back to "Open".

Thank you for your interest in PHP.

Explain to me what else I can tell you?

You can view the php.ini settings at http://snoopy.net/phpinfo.php.

If I call session_start(), there's no cookie, no session tmp files written, nothing, but php also produces no error.

No matter how I change the settings in php.ini, it doesn't change this behavior.

You can view the code I'm trying at:

http://anhold.com/ps/ses/index.phps
http://anhold.com/ps/ses/foo.phps

How are you checking that the cookie is or is not being set?

I set my browser (galeon/moz1.0) to warn me of cookies, and it's not warning me. (It is on other sites, or if I manually set a cookie with php)

reclassified.

Your samples work just fine for me on FreeBSD 4.6 and PHP 4.2.3... 

Are your permissions setup properly for the session to write to?

sorry, i could've sworn there was no "Session" category...

Do you have any errors in the logs?

drwxrwxrwt  5 root  wheel  5632 Sep 11 10:45 /tmp/

Everything else can write to /tmp..

No, nothing in the logs.

please make sure the category STAYS correct..

I tried changing session.save_path to something other than /tmp owned by the user which apache runs under (www), with no change in behavior. 

If I can find some decent mysql session handler code, i may try that to see if it works.

i've verified that cookies work..
http://anhold.com/cookie.php

-j

there's nothing being logged... how do I get debugging information out of php4?

configure php with the --enable-debug flag

Still convinced this a local install issue, and not a PHP issue as I cannot reproduce this bug on a FreeBSD 4.6 and 4.2.3 installation.  Have you had any luck getting it to work on your end?

Built with --enable-debug doesn't produce any more information that without it.. nothing in the log.

Installing php 4.1.2, everything works fine. Reinstall 4.2.3, no sessions.

yes, I'm just going to say 'me too' - (and I voted etc.) but thought that I'd say that I'm using win32/php4.2.3/apache2.0.40 and no matter what happens there are no cookies sent to the browser at any time whether there is an auto or manually started session, and that sessions (obviously) do not work using cookies.

I've tried changing all sorts of settings, including the safe modes, temp directories etc. - the old versions I had experienced trouble as well (sometimes working then stopping for no reason, then never going again) but I got around it using autostarted sessions etc. 

4.2.3 does not go for me at all
4.2.2 took some doctoring to go, eventually stopped
4.1.1 took some doctoring to go, eventually stopped
4.0.6 worked ok from what I remember

cheers for any fixes etc. and for your hard work on php :)

...and as if by magic, php4.2.3 starts sending cookies to the browser...

but sessions are still not working. If the cookie exists on the browser I assume its getting sent correctly to php (old code works, cookie tests I did worked fine), so its somewhere in the apache/php side that things are getting messed up from my uneducated observations.

...and you guessed it, sessions now come to life after a few restarts and head slaps.

This behaviour is consistent with previous versions and some bug reports I've read trying to find out why sessions weren't working - there are reports on win32 that sessions just stop one day and never go again (I've had this) - altho it appears with this version they suddenly start.

It still appears (after a few restarts) that they are a bit temperamental, sometimes going and sometimes not...

cheeers for reading my ramblings - good luck!

If session files are not even created, I suggest using truss(1) like this:

$ killall httpd
$ truss httpd -X 2> logfile
<..access a page which starts a session..>
<..hit ctrl-c..>

And then look for failed open() calls in the logfile..

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".