MCVE:
<?php
echo "testing!";
?>
Screenshot from accessing this script in Chrome:
Screenshot from running this script via the PHP command-line:
What's weird is that it hasn't always been this way. Everything was working perfectly yesterday, but ever since today, it's been doing this for whatever reason. Did I screw something up within the config of my Apache accidentally or something? Using XAMPP with PHP v7.3.8.
Wow, good catch KIKO Software! After checking the encoding of the file in Notepad++... I realized that it, for some reason, was set to "UCS-2 LE BOM". I changed it to "UTF-8" and now everything is working properly. Thank you!
In the most simple code possible
<?php
$ok = session_start();
echo var_dump($ok);
?>
starting the session fails, $ok is false and no session cookie is created. Likewise, naming the session using session_name('xxx'); has no effect. The $_SESSION variable also doesn't persist values if set in another script.
Other legacy scripts on the same server that use the session feature work as expected. The same script works fine when run on localhost.
The steps I did during error analysis where:
I removed naming the session and everything else to get the script above (bare minimum example reproduces the error).
I checked the error log my provider offers, but no entry at all was found
I made sure that no additional whitespace is present, and all scripts immediately start with session_start().
In the same script I showed phpinfo() to mark that:
Session Support: enabled
session.auto_start: Off
session.use_cookies: 1
session.use_only_cookies: 1 (disputed, but since other scripts work...)
I started doubting my sanity.
I remembered running into "invisible characters" in form of byte-order-marks in text files before and figured, that maybe something like encoding might be a problem (see answer below) ...
What are additional sources for error that could cause these symptoms?
The problem was, that the script files were encoded as what Notepad++ calls UTF-8 BOM under Windows.
Converting it to straight UTF-8 in Notepad++ and reuploading the scripts immediately fixed all problems.
So I guess that somewhere in the files a stray byte order mark was left that caused the php installation on the server to not recognize or fail to parse the script file.
Edit: The same root cause was described in much more detail by mario at https://stackoverflow.com/a/8028987/3055288
I'have just started to learn PHP, I'm using a free host to test my code but nothing happens and also my php code passed in source of page, does it show that server don't interpret it?
Yes, that shows that the server isn't interpreting it properly. The user should never receive PHP code, just the html/javascript/whatever that your PHP script outputs.
As for why this is happening, here are a few basic things to check:
Your PHP code should begin with the <?php tag and end with the ?> tag (the ending tag isn't strictly necessary, but any code you put after it won't be interpreted).
The document's name should end with .php (not always necessary, but some server setups may require it).
If you haven't checked already, make sure that the host you're using supports PHP in the first place.
Is php code passed in source to the client?
No.
Your PHP interpreter isn't being invoked.
I don't have access to the apache server or whatever is running on the server. I just have a free account with a web host. I do apparently have access to the .htaccess file, but I'm not sure if I feel safe enough to temper with the "nuts and bolts" as it were. So instead I tried to enable debug printouts in my php script like so:
error_reporting(E_ALL);
I'm not seeing any errors, but I know that there is an error since the entire script isn't executing.
Is there an easy way to get error printouts to show in the code that php returns? If I tried to temper with .htaccess, what would I have to do there? It's only 36 bytes long.
DO:
error_reporting(E_ALL);
ini_set('display_errors',"On");
You could also try debug_backtrace().
var_dump(debug_backtrace());
since a few hours our server hangs every time you do a session_start.
For testing purposes i created a script which looks like this:
<?php
session_start();
?>
Calling it from the console hangs and it can't even be stopped with ctrl-c, only kill -9 works. The same for calling it via Apache. /var/lib/php/session/ stays empty but permissions are absolutely fine, www can write and also has read permissions for all parent folders.
According to the admins there were no changes made on the server and there is no special code registered for sessions. The Server is CentOS 4 or 5 and yesterday everything was working perfectly. We rebooted the server and updated PHP, but nothing changed.
I've ran out of ideas, any suggestions?
UPDATE
We solved this problem by moving the project to another server, so while the problem still exists on one server there is no immediate need for a solution anymore.
I will keep the question open in case someone has an idea for others having a similar problem in the future, though.
There are many reasons for that, here are a few of them:
A. The session file could be opened exclusively.
When the file lock is not released properly for whatever reason, it is causing session_start() to hang infinitely on any future script executions.
Workaround: use session_set_save_handler() and make sure the write function uses fopen($file, 'w') instead of fopen($file, 'x')
B. Never use the following in your php.ini file (entropie file to "/dev/random"), this will cause your session_start() to hang:
<?php
ini_set("session.entropy_file", "/dev/random");
ini_set("session.entropy_length", "512");
?>
C.
session_start() needs a directory to write to.
You can get Apache plus PHP running in a normal user account. Apache will then of course have to listen to an other port than 80 (for instance, 8080).
Be sure to do the following things:
- create a temporary directory PREFIX/tmp
- put php.ini in PREFIX/lib
- edit php.ini and set session.save_path to the directory you just created
Otherwise, your scripts will seem to 'hang' on session_start().
If this helps:
In my scenario, session_start() was hanging at the same time I was using the XDebug debugger within PHPStorm, the IDE, on Windows. I found that there was a clear cause: Whenever I killed the debug session from within PHPStorm, the next time I tried to run a debug session, session_start() would hang.
The solution, if this is your scenario, is to make sure to restart Apache every time you kill an XDebug session within your IDE.
I had a weird issue with this myself.
I am using CentOS 5.5x64, PHP 5.2.10-1. A clean ANSI file in the root with nothing other than session_start() was hanging. The session was being written to disk and no errors were being thrown. It just hung.
I tried everything suggested by Thariama, and checked PHP compile settings etc.
My Fix:
yum reinstall php; /etc/init.d/httpd restart
Hope this helps someone.
To everyone complaining about the 30 seconds of downtime being unacceptable, this was an inexplicable issue on a brand new, clean OS install, NOT a running production machine. This solution should NOT be used in a production environment.
Ok I face the same problem on 2 PC, 1 is MAC mini XAMPP, 1 is Windows 10 Xampp.
Both is php spent infinity to run session_start(). Both PHP version is 7.x.x
I found that session files is lock to read and write. So that I added code to make PHP read session files and immediately unlock when done with
<?php
session_start([
'read_and_close' => true,
]);
?>
or
<?php
//For PHP 5.x
session_start();
session_write_close();
?>
After this PHP unlock session file => Problems solve
The problem: -
Iv experienced (and fixed) the problem where file based sessions hang the request, and database based sessions get out of sync by storing out of date session data (like storing each session save in the wrong order).
This is caused by any subsequent request that loads a session (simultaneous requests), like ajax, video embed where the video file is delivered via php script, dynamic resource file (like script or css) delivered via php script, etc.
In file based sessions file locking prevents session writing thus causing a deadlock between the simultaneous request threads.
In database based session the last request thread to complete becomes the most recent save, so for example a video delivery script will complete long after the page request and overwrite the since updated session with old session data.
The fix: -
If your ajax or resource delivery script doesnt need to use sessions then easiest to just remove session usage from it.
Otherwise you'd best make yourself a coffee and do the following: -
Write or employ a session handler (if not already doing so) as per http://www.php.net//manual/en/class.sessionhandler.php (many other examples available via google search).
In your session handler function write() prepend the code ...
// processes may declare their session as read only ...
if(!empty($_SESSION['no_session_write'])) {
unset($_SESSION['no_session_write']);
return true;
}
In your ajax or resource delivery php script add the code (after the session is started) ...
$_SESSION['no_session_write'] = true;
I realise this seems like a lot of stuffing around for what should be a tiny fix, but unfortunately if you need to have simultaneous requests each loading a session then it is required.
NOTE if your ajax or resource delivery script does actually need to write/save data, then you need to do it somewhere other than in the session, like database.
Just put session_write_close(); befor Session_start();
as below:
<?php
session_write_close();
session_start();
.....
?>
I don't know why, but changing this value in /etc/php/7.4/apache2/php.ini worked for me:
;session.save_path = "/var/lib/php/sessions"
session.save_path = "/tmp"
To throw another answer into the mix for those going bananas, I had a session_start() dying only in particular cases and scripts. The reason my session was dying was ultimately because I was storing a lot of data in them after a particularly intensive script, and ultimately the call to session_start() was exhausting the 'memory_limit' setting in php.ini.
After increasing 'memory_limit', those session_start() calls no longer killed my script.
For me, the problem seemed to originate from SeLinux. The needed command was chcon -R -t httpd_sys_content_t [www directory] to give access to the right directory.
See https://askubuntu.com/questions/451922/apache-access-denied-because-search-permissions-are-missing
If you use pgAdmin 4 this can happen as well.
If you have File > Preferences > SQL Editor > Options > "Auto Commit" disabled, and you just ran a query using the query tool but didn't manually commit, then session_start() will freeze.
Enable auto commit, or manually commit, or just close pgAdmin, and it will no longer freeze.
In my case it seems like it was the NFS Share that was locking the session , after restarting the NFS server and only enabled 1 node of web clients the sessions worked normally .
Yet another few cents that might help someone. In my case I was storing in $_SESSION complex data with several different class objects in them and session_start() couldn't handle the whole unserialization as not every class was loaded on session_start. The solution is my case was to serialize/jsonify data before saving it into the $_SESSION and reversing the process after I got the data out of session.