Edit report at https://bugs.php.net/bug.php?id=16263&edit=1
ID: 16263
Comment by: phpbugs at aron dot ws
Reported by: kur at natur dot cuni dot cz
Summary: session.start() create new empty session file and
not resume existing session
Status: No Feedback
Type: Bug
Package: Session related
Operating System: ANY
PHP Version: 4.3.0-dev
Block user comment: N
Private report: N
New Comment:
If you run out of space you get the same effect :D
Previous Comments:
------------------------------------------------------------------------
[2010-09-23 22:21:55] sartorato at gmail dot com
Hi there,
I was having the same problem with PHP creating session files with 0Kb.
I solved putting the <? session_start();?> on the first line of the php file.
After this it works like a charm.
Hope it helps somebody.
Ricardo Sartorato
------------------------------------------------------------------------
[2009-12-16 20:07:04] sven dot holcombe at gmail dot com
Running on default XAMPP installation, with the
session.save_path = "C:\xampplite\tmp"
When I set the apache document root to be:
<Directory "C:/xampplite/htdocs">
And then run a file with contents:
<?PHP session_start(); ?>
There is a session file created. Ie, normal operation.
When I set the apache document root to be:
<Directory "S:/htdocs">
And then run THE SAME file with contents:
<?PHP session_start(); ?>
A 0KB session file is created. Ie, it is empty, and I cannot access session
variables.
Please help.
------------------------------------------------------------------------
[2009-12-02 18:57:14] john at 5070 dot info
The same issue.
# php-cgi -v
PHP 5.2.6-1+lenny3 with Suhosin-Patch 0.9.6.2 (cgi-fcgi) (built: Apr 26 2009
22:11:16)
Copyright (c) 1997-2008 The PHP Group
Zend Engine v2.2.0, Copyright (c) 1998-2008 Zend Technologies
with eAccelerator v0.9.5.3, Copyright (c) 2004-2006 eAccelerator, by
eAccelerator
with Zend Extension Manager v1.2.2, Copyright (c) 2003-2007, by Zend
Technologies
with Suhosin v0.9.27, Copyright (c) 2007, by SektionEins GmbH
with Zend Optimizer v3.3.3, Copyright (c) 1998-2007, by Zend Technologies
System call trace (in fact, this is processed by mod_php of the same version):
open(".../sess_a6549.............", O_RDWR|O_CREAT|O_LARGEFILE, 0600) = 1035
fstat64(1035, {st_mode=S_IFREG|0600, st_size=96, ...}) = 0
flock(1035, LOCK_EX) = 0
fcntl64(1035, F_SETFD, FD_CLOEXEC) = 0
fstat64(1035, {st_mode=S_IFREG|0600, st_size=96, ...}) = 0
_llseek(1035, 0, [0], SEEK_SET) = 0
read(1035, "Acess|s:1:\"1\";id|s:3:\"108\";login|"..., 96) = 96
...
ftruncate64(1035, 0) = 0
_llseek(1035, 0, [0], SEEK_SET) = 0
write(1035, ""..., 0) = 0
close(1035) = 0
Session files are shared via NFSv4, if it is important.
------------------------------------------------------------------------
[2009-08-26 18:00:41] chris dot kerrison at farrendale dot co dot uk
Hello, I have theis session problem, tried everything on this page not still
wont work. Is anyone else having the problem still??
I have 2 servers, one it works fine on and the other it fails, they use the
same settings, and have tried differant versions, yet it still fails on the 2nd
server.
Ho many people here are running it on a server with a " _ " in the computer
name? that to me seems the only thing differant between the computers with my
setup.
------------------------------------------------------------------------
[2008-09-12 23:42:19] robin dot chauhan at gmail dot com
As noted on http://www.kirupa.com/forum/showthread.php?t=288773
"After 10 hours of searching over 2 days, I figured it out. The UTF-8 encoding
was placing invisible characters before my <?php tag, thus throwing an error
(which I couldn't see because my server host's debug doesn't show). Switching
to ANSI removed those characters and thus the session_start() functioned
properly this time, giving me a consistent session ID. Thanks to those who
helped."
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=16263
--
Edit this bug report at https://bugs.php.net/bug.php?id=16263&edit=1
