Update 0.4.4 error index.php


(monpcsecurise) #1

Following is the update Piwik in 0.4.4, I get the following error that appears?
Warning: is_writable () [function.is-writable]: open_basedir restriction in effect. File (/ var / lib / php / session) is not within the allowed path (s): (/ var / www / vhosts / monpcsecurise.fr / subdomains / stat / httpdocs: / tmp) in / var / www / vhosts / monpcsecurise.fr / subdomains / stat / httpdocs / index.php on line 55

Do you have a solution?

Thank you


(kionez) #2

is the same here, updating to newest version (0.4.4)


(MaNIaC) #3

Hi,

sadly i have the same problem here. I first tried the update automatically and that caused a big error. But it updated anyway…
Since then i’ve been getting that error all over the place…

Have tried doing the update manually but that also causes the same error again…

Only in my case it says:

Warning: is_writable(): open_basedir restriction in effect. File(/var/lib/php5) is not within the allowed path(s): (/srv/www/vhosts/mydomain/subdomains/stats/httpdocs:/tmp) in /srv/www/vhosts/mydomain/subdomains/stats/httpdocs/index.php on line 55

Have been looking threw the code, but haven’t found anything, yet. Im gonna compare it a little with 0.4.3 in the index.php maybe i’ll find something…or not…(which i don’t hope).

Has anybody already found a solution?

Thx in advance

greetz
MaNIaC


(MaNIaC) #4

Hi,

me again. I think i found something!
“Problem” is somewhere concering session handling.

In the last release the index.php only had this part:

if(ini_get('session.save_handler') == 'user')
{
    @ini_set('session.save_handler', 'files');
    @ini_set('session.save_path', '');
}

In the new release the actual session.save_path is being checked.

if(ini_get('session.save_handler') == 'user')
{
    @ini_set('session.save_handler', 'files');
    @ini_set('session.save_path', '');
}
if(ini_get('session.save_handler') == 'files')
{

    if(!is_writable(ini_get('session.save_path')))
    {
        $sessionPath = PIWIK_USER_PATH . '/tmp/sessions';
        @ini_set('session.save_path', $sessionPath);
        if(!is_dir($sessionPath))
        {
            @mkdir($sessionPath, 0755, true);
        }
    }
}

I tried quoting the whole “if” that checks if the session.save_path is writeable and changes it if not and that lets piwik run again without any error. For now…
So that area looks like this now in my index.php:

if(ini_get('session.save_handler') == 'user')
{
    @ini_set('session.save_handler', 'files');
    @ini_set('session.save_path', '');
}
/*
if(ini_get('session.save_handler') == 'files')
{

    if(!is_writable(ini_get('session.save_path')))
    {
        $sessionPath = PIWIK_USER_PATH . '/tmp/sessions';
        @ini_set('session.save_path', $sessionPath);
        if(!is_dir($sessionPath))
        {
            @mkdir($sessionPath, 0755, true);
        }
    }
}
*/

The reason why the whole error shows up is, as far as i can tell atm:

The function “is_writable” tries to check the “session.save_path” (which in my case is /var/lib/php5). But the server (php itself, or so) restricts (through the open_basedir) the user to the root folder of the page (httpdocs) and the /tmp folder…

Question is:

Is it really necessary to check if the session.save_path is writeable? It was not done in the old version of piwik (At least nowhere were i looked), so why now?
Hope this helps some people and doesn’t do something bad…style_emoticons/<#EMO_DIR#>/happy.gif o_O

greetz
MaNIaC

[EDIT]
After reading a little throuh the changelog i read that the function to check if save_path is writeable was inserted because of problems if it wasn’t.
So it kind of should be there if the server is really set that way.
But as far as i remember the Server is only set that way if safe_mode is active…normally it should always be writeable (without safe_mode)!

For now i’ll keep that “check” commented.
[/EDIT]


(vipsoft) #5

Can you try using the @ syntax?

    if(!@is_writable(ini_get('session.save_path')))

We added this check because it’s not writeable on some hosts and prevents saving session data.


(monpcsecurise) #6

OK all works correctly!

thank you very much!


(MaNIaC) #7

Hi vipsoft,

was a little slow with my EDIT…style_emoticons/<#EMO_DIR#>/happy.gif

Tried your correction: WORKS!

Short question or reminder for me: What does the @ say again? My php is a little rusty… style_emoticons/<#EMO_DIR#>/happy.gif

Thx for the help!

greetz
MaNIaC


(monpcsecurise) #8

[quote=MaNIaC @ Oct 21 2009, 03:11 PM]Hi vipsoft,

was a little slow with my EDIT…style_emoticons/<#EMO_DIR#>/happy.gif

Tried your correction: WORKS!

Short question or reminder for me: What does the @ say again? My php is a little rusty… style_emoticons/<#EMO_DIR#>/happy.gif

Thx for the help!

greetz
MaNIaC[/quote]

I just read on another forum that @ in PHP does not display the error function, so it corrects the problem without really knowing why we had this


(eugen723674) #9

hi!

Hi had 100% the same bug/error and i thought its my fault … just installed piwik 4th time new!!!

So what should i do now exactly (official fix from piwik needed) to fix this?
And why could this happen??? Don’t you test your updates befpre sending them live on thousands on live-piwiks? style_emoticons/<#EMO_DIR#>/sad.gif
and why isn’t there an official sticky fix-thread about this issue as this error seems to effect very much piwik installations?

EDIT:
i am running piwik on 2 different servers. one got this problem descriped above and the other does not!
also i noticed that one installations needs /tmp to be 777 , the other likes 755!
also one installation uses the /tmp/sessions folder, the other installation doesnt even create this /tmp/session folder!
also one installation generated something like a /tmp/cache/tracks folder including a folder for each tracking id, the other installation doesnt!

Is this all regular and normal? style_emoticons/<#EMO_DIR#>/smile.gif

Best Regards
Eugen


(vipsoft) #10

We do test Piwik. Unfortunately, it’s not practical to test all the possible configurations, operating systems, or versions of php/mysql.

In your case, Piwik is adapting to differences in each server.


(vipsoft) #11

Thanks for verifying the fix.

We’ve pushed 0.4.5. If Piwik is now working for you, then you’re in no immediate need to update.