No users showing online due to session errors

[mmlr38]

OK, I'm still getting this error with the newest version 1.0.5 of ArrowChat.

Additionally, I'm getting another error that basically renders the chat software useless because it shows no one online:

Code: Select all

[Mon Mar 07 18:30:12 2011] [error] [client 66.241.83.185] PHP Notice:  A session had already been started - ignoring session_start() in /PATH_TO_WEB_DIR/arrowchat/receive/receive_core.php on line 65, referer: http://www.flytrapcare.com/
[Mon Mar 07 18:30:12 2011] [error] [client 66.241.83.185] PHP Fatal error:  session_start() [<a href='function.session-start'>function.session-start</a>]: Failed to initialize storage module: user (path: /var/lib/php5) in //PATH_TO_WEB_DIR/arrowchat/receive/receive_core.php on line 381, referer: http://www.flytrapcare.com/

I think this might be a known bug in PHP:
http://bugs.php.net/bug.php?id=25876

I'm running PHP 5.2.6 and ArrowChat requirements say that any version of PHP 4.3.3 or greater should work. Why then should I have to spend my time and energy debugging code that I paid someone for? Or why should I have to pay again for support of buggy code?

And since when did ArrowChat stop addressing problems posted on the forums and require customers to pay for support through tickets? I feel a bit like I was blind-sided by this change and didn't see it coming when I originally paid for the chat software.

Seems a bit shady to me to not inform customers initially that support isn't included in the purchase price and then start releasing software with problems in it and make people pay to fix the problems in the code.

Doesn't seem right to me to make people pay to fix problems in code that they already paid for.

[Jason]

You're welcome to submit bug reports at any time without technical support (yes, we do fix all of them). However, this particular issue is not a bug.

We've been notifying users for a long, LONG time that support will be reset and expire after 30 days from v1.0. This couldn't have been more clear as it was posted many, many times. You received over a year of free technical support and two years of free updates just because we felt that the clock shouldn't start ticking until v1.0. That free ride has finally come to an end. As active as you were in the community, I find it hard to believe that you missed this information.

As for your problem, just remove all the session_start() code.

[mmlr38]

Thanks for the help with fixing this Jason.

You're welcome to submit bug reports at any time without technical support (yes, we do fix all of them). However, this particular issue is not a bug. We've been notifying users for a long, LONG time that support will be reset and expire after 30 days from v1.0. This couldn't have been more clear as it was posted many, many times.

It's really not the fact that support ends after 30 days that wasn't made clear. That was clear and I understand that.

It's that I feel that a software product, provided you have all of the requirements as listed by the company distributing it, should work correctly out of the box. And if it doesn't work right out of the box (I've made no modifications to this code), then how is that not a bug?

I've paid my money for working software (I actually have two licenses). And I have all of the requirements as listed in your requirements page here:
http://www.arrowchat.com/index.php?do=requirements

I followed the install instructions and I'm actually fairly technically astute. So why then do I have to pay for support to fix problems with the code? The last time I submitted a request to help fix a problem, I got a response that I needed to pay for support. But this is not how I view support. As I understand it, support is when someone has problems with an installation or doesn't understand how to set up the software correctly. I know how to do that.

The problems I'm having are with the software not functioning correctly after proper installation on a system that meets the requirements as stated by ArrowChat. That, I feel, should not require additional money from me, a customer that paid for working software, to be fixed.

Do you feel like I'm wrong here?

[Jason]

No, I don't think you're wrong. However, we generally don't fix bugs in technical support tickets unless it's an urgent issue. No matter how hard we try, there will always be bugs, but we do have the bug report section and urgent ones are usually fixed within a few days, and low and medium priority with the next update. Technical support is more for people that install it wrong.

By the way, we are going to go back and take a look at how sessions are handled in that file.

[asinsh]

Just curious: it seems like most people have not run into this problem (in any event, I haven't), so is this happening to mmlr32 as a result of the way his (or his host's) php.ini file is configured? If so, it would probably be useful to let people know what entry needs to be in php.ini to fix the problem.

[mmlr38]

Thanks for the reply Jason.

As a programmer, I know where you're coming from. You're right that there will always be bugs (at least small ones) no matter how hard you try. And trying to create something that works on many different servers is a real challenge.

I was just frustrated when I submitted a support ticket and received a response that I needed to pay to have support. I didn't realize that there was a separate place to submit bugs. But I see it here now:
tracker.php?p=1

And thanks for looking at how sessions are handled in the receive_core.php file.

Just curious: it seems like most people have not run into this problem (in any event, I haven't), so is this happening to mmlr32 as a result of the way his (or his host's) php.ini file is configured? If so, it would probably be useful to let people know what entry needs to be in php.ini to fix the problem.

That's a good thought asinsh. You know...the chat seemingly worked even with the fatal errors. I could still use it to chat with people. Though many people were complaining that they knew that their friends were online, but still couldn't chat with them, so I took a look at the error log and found this problem. Perhaps it's afflicting many others but they don't even know it because it doesn't completely prevent ArrowChat from working.

[asinsh]

Just curious: it seems like most people have not run into this problem (in any event, I haven't), so is this happening to mmlr32 as a result of the way his (or his host's) php.ini file is configured? If so, it would probably be useful to let people know what entry needs to be in php.ini to fix the problem.

That's a good thought asinsh. You know...the chat seemingly worked even with the fatal errors. I could still use it to chat with people. Though many people were complaining that they knew that their friends were online, but still couldn't chat with them, so I took a look at the error log and found this problem. Perhaps it's afflicting many others but they don't even know it because it doesn't completely prevent ArrowChat from working.

I had the same thought, but I checked my error log and it's totally clean. I suppose it's possible that others are getting errors in their logs that they never find out about (a lot of people don't know where their logs are ;) ).

[asinsh]

If you look at your php.ini file, what do the lines that begin with:

session.save_handler
and
session.save_path

look like?

If they don't look like the following, try as an experiment to change them to the following just to see if that's it:

Code: Select all

session.save_handler = files
session.save_path = /tmp

This is not based on any particular knowledge I have about how sessions are handled in php, but rather is something that comes up on a number of the results I got when googling these errors.

[mmlr38]

If you look at your php.ini file, what do the lines that begin with:

session.save_handler
and
session.save_path

look like?

If they don't look like the following, try as an experiment to change them to the following just to see if that's it:

Code: Select all

session.save_handler = files
session.save_path = /tmp

This is not based on any particular knowledge I have about how sessions are handled in php, but rather is something that comes up on a number of the results I got when googling these errors.

Thanks for the suggestion Asinsh. I actually did quite a bit of Googling trying to figure out how to fix the problem and probably read some of the same articles you did to come up with your suggestion because it was something that I've previously looked at. The server runs on Ubuntu. It already has:

Code: Select all

session.save_handler = files

But the directory where sessions are saved by default is:

Code: Select all

session.save_path = /var/lib/php5

Sessions seem to work fine on the phpBB3 installation we have and with Magento ecommerce software. I don't know why errors are being thrown with the ArrowChat code.

[Jason]

Which integration are you running? I believe it has something to do with the initialization of the integration in the config.php file beforehand.

[asinsh]

I use on phpbb3 too and get no errors, so it really does sound like the difference is the content of our php.ini files. Could you humor me and change your session.save_path entry to /tmp
(You can change it back right after you test ;) ).

[mmlr38]

Which integration are you running? I believe it has something to do with the initialization of the integration in the config.php file beforehand.

I'm running the JomSocial integration and the arrowchat directory is in my root directory. That's correct isn't it?

I use on phpbb3 too and get no errors, so it really does sound like the difference is the content of our php.ini files.

I think I wasn't clear before. I don't use ArrowChat on a phpBB3 integration. I use it on a JomSocial integration. But I also run phpBB3 and Magento on the sever.

Could you humor me and change your session.save_path entry to /tmp
(You can change it back right after you test ;) ).

Hmmm, I would do that test if I believed that it would make a difference. What is your logic behind wanting to make that change? Does it matter which directory the sessions are written to? Both the /var/lib/php5 directory and the /tmp directory are writable and I can see the session files for phpBB3 and Magento being created just fine in the /var/lib/php5 directory.

[asinsh]

Could you humor me and change your session.save_path entry to /tmp (You can change it back right after you test ;) ).

Hmmm, I would do that test if I believed that it would make a difference. What is your logic behind wanting to make that change? Does it matter which directory the sessions are written to? Both the /var/lib/php5 directory and the /tmp directory are writable and I can see the session files for phpBB3 and Magento being created just fine in the /var/lib/php5 directory.

It's probably fine as is (you are right that the posts I saw mentioning this issue focused on whether the path was writable) but I figured it was super easy to change just to test and there were a lot of posts about ubunto setups in particular where people had trouble with paths other than /tmp. Up to you.

Whatever happens, hope you get it sorted out.

[JSaverino]

I am having the same issue as mmlr38. I also am running Ubuntu, ArrowChat with JomSocial Integration and I'm using phpBB with Blogomunity Bridge.

Has there been any further on this matter? Thanks

[Staff Bot]

This thread has been locked because the last post is greater than six months old. There is a good chance that the information in this thread is outdated. Please open a new topic if you wish to discuss this further.