Bought YShout and have been running on my webserver for some time now. Support isn't answering any emails in a long time. I keep getting unserialize errors that kill the chat box.
Error: There appears to be a problem: unserialize() Error at offset 65537 of 86434 bytes. File: filestorage.class.php Line 36.
Here is the function with line 36 in it.
function load() {
if (($contents = $this->read($this->path)) == null)
return $this->resetArray();
return unserialize($contents);///////////line 36
}
here seems to be the line in the log file that is generating the error message, 65537 seems to be located right at the "a" in "uia:2:" in the string.
i:251;a:6:{s:8:"nickname";s:7:"TestUser";s:7:"message";s:30:"when he's online ask him";s:9:"timestamp";d:1373857811.6403610706329345703125;s:5:"admin";b:0;s:3:"uia:2:{s:4:"info";a:1:{s:15:"latestTimestamp";i:-1;}s:5:"posts";a:0:{}}ip";s:12:"76.174.54.75";}}
Not really sure how YShout works, but I'm getting this error more than once a day now. I have to delete the log file, then YShout creates a new log from scratch and all is well. But until I delete the log causing problems no one can use the chat window.
Ideal solution would be to fix this and figure out whats going on. Secondary solution would be to rename the log file causing the error. This would cause YShout to create a new log file to use and we would have a history of the log that contained the error message.
I had the same error message appearing when I was messing with the log file. If you add or remove characters from a message you'll end up with this error. But altering characters won't cause any trouble. So that means that YShout is storing message lengths in the log file.
Look at this line:
s:30:"when he's online ask him";
's' states that 30 characters are being used, but your message is only 24 characters long. Try changing it to 24 and the problem should be fixed.
Related
I am currently building a small application that uses the message queue built in PHP.
I have 1 "server" process and 1 "client" process. Messages flow from server to client.
They are simple JSON objects, that are serialised, then send.
This code is used
<?php
$send = msg_send($q, MESSAGE_TYPE_EXECUTION, $update, true, false, $error);
if (isset($error) && $error != 0) {
echo 'Execution error: ' . $error . PHP_EOL;
}
// $q is the message queue integer
// MESSAGE_TYPE_EXECUTION is integer 1
// $update is the JSON string
// true is that the JSON string is serialised
// false is that it is blocking (which it is not)
// $error get's filled when an error occurs (see below)
This works without issue, until it does not.
Sometimes after a couple of minutes, sometimes after a couple of hours the following error appears:
PHP Warning: msg_send(): msgsnd failed: Resource temporarily unavailable in
/var/www/server.php on line 57
The value of the $error variable is the integer 11.
All messages that follow this error will have error 11, until I restart the process and all is working again (for a while, until the same error appears again)
I have been searching but cannot find any explanation what error 11 is, how this can be managed and fixed without restarting the process.
Any clue, information, example etc is welcome. I would really like for server.php to be reliable.
-- edit --
client.php is the process that fetches the messages (which are all more or less the same, but with other values)
it uses this fetch the messages from the queue (filled in server.php)
<?php
$update = msg_receive($q, 0, $messagetype, 1024, $message, true, MSG_IPC_NOWAIT && MSG_NOERROR, $error);
if ($update) {
// Do stuff
}
usleep(1000000);
I have not yet checked memory usage, will look into that
Platform used
PHP 7.1.3
Centos 7
So, Solution was found after some information and leads (read the comments on my original question), brought up by #ChrisHaas (Thanks again!). After some tinkering all is running smoothly now, without error 11 for msg_send().
PHP msg_send() call is basically a wrapper of msgsnd
So a lot of information can be found there, also about errors you might encounter (in combination with flags used when reading messages with msg_receive() )
The queue is limited in total size and total messages it can hold (I, however, have not found a way to increase the total size of the queue).
The reason I was getting error 11 was due to a couple of things:
The client I created was too slow fetching messages from the queue, causing it to run into the max limit and crapping out. I did not find a solution for fixing this situation, other than restarting all processes involved. To repeat the same over and over again.
I also increased the size of reading messages in msg_receive() as sometimes the messages where big (most where small). But when you declare a too small size the big messages will remain in queue and clog it up until it craps out. Increasing the max_size helped with fetching the bigger messages too.
Long story short: error 11 is related to a full message queue in my perspective (I still do not have a 100% clear documented answer though).
Pointers to fix the issue:
Be sure you fetch all messages that are big.
Be sure to read out at least as fast as you send the messages in the queue.
Check your queue(s) with the command ipcs -q in the terminal. It allows you to see the queues currently active. Keeping an eye on that allows you to see it slowly filling up on problems.
Wish the documentation on php.net was better in this case...
I have written a script that search for values in xml file. This files I retrieve online via the following code
# Reads entire file into a string
$result = file_get_contents($xml_link);
# Returns the xml string into an object
$xml = simplexml_load_string($result);
But the xml are somethimes are big with as consequence that I got the following error Fatal error: Maximum execution time of 30 seconds exceeded.
I have adapted the ini.php files to max_exucution time set to a 360 seconds but I still got the same error.
I have two options in mind.
If this error occurs run the line again. But I couldn't find anything online (I am probably searching with wrong searchterms). Is there a possibility to run the line where the error occurs again?
Save the xml files temporary local and search for the information in this way and remove in the end of the process. Here , I have no idea how to remove them after retrieving all data? And would this actually solve the problem? Because my script still needs to search through the xml file? Will it not take the same amount of time?
When I used these two lines in my script the problem was solved.
ini_set('max_execution_time', 300);
set_time_limit(0);
I have a problem with PHP filemtime function. In my webapp I use Smarty template engine with caching option. In my webapp I can do some actions which generate error, but lets focus on only one action. When I click link on page some content is updated - I can click few times and everything is OK but about one request on 10 fails. Following error occurs:
filemtime() [<a href='function.filemtime'>function.filemtime</a>]: stat failed for
and the line that causes the problem:
return ($_template->getCachedFilepath() && file_exists($_template->getCachedFilepath())) ? filemtime($_template->getCachedFilepath()) : false ;
As you can see, file exists because it is checked.
Problematic line of code is included in smarty_internal_cacheresource_file.php (part of Smarty lib v3.0.6)
App is run on UNIX system, external hosting.
Any ideas? Should I post more details?
file_exists internally uses the access system call which checks permissions as the real user, whereas filemtime uses stat, which performs the check as the effective user. Therefore, the problem may be rooted in the assumption of effective user == real user, which does not hold. Another explanation would be that the file gets deleted between the two calls.
Since both the result of $_template->getCachedFilepath() and the existance of the file can change in between system calls, why do you call file_exists at all? Instead, I'd suggest just
return #filemtime($_template->getCachedFilepath());
If $_template->getCachedFilepath() can be set to a dummy value such as false, use the following:
$path = $_template->getCachedFilepath();
if (!$path) return false;
return #filemtime($path);
Use:
Smarty::muteExpectedErrors();
Read this and this
I used filemtime successfully without checking "file_exists" for years. The way I have always interpreted the documentation is that FALSE should be returned from "filemtime" upon any error. Then a few days ago something very weird occurred. If the file did not exist, my Cron job terminated with a result. The result was not in the program output but rather in the Cron output. The message was "file length exceeded". I knew the Cron job ended on the filemtime statement because I sent myself an email before and after that statement. The "after" email never arrived.
I inserted a file_exists check on the file to fix the Cron job. However, that should not have been necessary. I still do not know what was changed on the hosting server I use. Several other Cron jobs started failing on the same day. I do not know yet whether they have anything to do with filemtime.
Short story
I've got a PHP script filtering incoming mail using a .qmail file. The script works perfectly well and logs all activity but, as far as I know, the last .qmail line shouldn't be executed when my script returns a dot-qmail exit code 99 that should stop processing further .qmail lines.
Long story:
I'm using a Parallels Plesk Panel version 9.3.0 under Linux 2.6.18-4-686.
My PHP CLI version is 5.2.0-8+etch16 (cli) (built: Nov 24 2009 11:14:47).
Not satisfied with Spamassassin, Dr. Web and zen.spamhaus.org and their results, I decided to create my own PHP script for filtering all incoming mail.
(An aside to some of you who might think "this guy is reinventing the wheel": I know my customers personally and their specific needs so, after thousands of tests, this turned out to be the best option because it avoids black box models and lets me control the process in a comprehensive way, also freeing server resources and opening doors to other cool functionality).
However I'm having a hard time installing the script at the server.
qmailfilter is my script and you can see it at http://titanpad.com/1IFDj1jvB0
I edited an existing .qmail file in /var/qmail/mailnames/customerdomain.com/username/.qmail to be:
|/var/my/qmailfilter/qmailfilter
|/usr/bin/deliverquota ./Maildir
qmailfilter PHP script executes and logs perfectly when I send a message to this user account, returns the exit code (99 for discarding message and 0 for proceeding to next .qmail line delivering the message).
Turns out that it delivers the message irrespectively of the many exit codes I've already tried.
The script (see line 174) outputs a text exit code without any whitespace before or after. I tried exit($code), print $code, echo($code) and even file_put_contents("php://stdout", $code), and also exit(chr($code)).
dot-qmail codes are:
0 - Success (go to next .qmail line)
99 - Success and abort (do not execute next lines)
100 - permanent error (bounce)
111 - soft error (retry later)
Source: The Big Qmail Picture.
Other attempts/experiments:
Removed the shebang line (#!/usr/bin/php) and changed the first .qmail line to |php -q /var/my/qmailfilter/qmailfilter
Checked the last line of the script for whitespacing
Read dot-qmail man file but nothing conclusive was found
Joined .qmail lines:
|/var/my/qmailfilter/qmailfilter |/usr/bin/deliverquota ./Maildir
In this case I got a message having only the proper return code without any header, subject or message body.
Commented out (#) the second .qmail line, but stopped receiving any kind of messages.
Edited /var/qmail/control/defaultdelivery to add a first line:
|php /var/my/qmailfilter/qmailfilter
|/usr/bin/deliverquota ./Maildir
and renamed user .qmail file to _qmail. Same results.
Should I deliver the message via PHP script and forget exit codes?
If so, is it enough to save the message to the user Maildir/new?
If so, is the message filename important?
Any idea will be appreciated. Thanks very much!
UPDATE: For those of you who need it, I published the final script at icebex.com slash qmailfilter
I only took a quick look at the code, but it looked like you were using string values. exit('99') and exit(99) are not the same. Make sure you use integers and not strings.
exit('99') will print 99 and return 0.
exit(99) will return 99.
I am using the following code fragment in a php script to safely update a shared resource.
$lock_id = sem_get( ftok( 'tmp/this.lock', 'r'));
sem_acquire($lock_id)
//do something
sem_release($lock_id)
When I stress test this code with large number of requests I get an error:
Warning: semop() failed acquiring SYSVSEM_SETVAL for key 0x1e: No space left on device in blahblah.php on line 1293
php sources show the following code for failed acquiring SYSVSEM_SETVAL
while (semop(semid, sop, 3) == -1) {
if (errno != EINTR) {
php3_error(E_WARNING, "semop() failed acquiring SYSVSEM_SETVAL for key 0x%x: %s", key, strerror(errno));
break;
}
}
which means semop fails with EINTR. man page reveals that the semop() system call was interrupted by a signal.
My question is can I safely ignore this error and retry sem_acquire?
Edit: I have misunderstood this problem, Pl see the clarification I have posted below.
raj
I wouldn't ignore the ENOSPC (you're getting something other than EINTR, as the code shows). You may end up in a busy loop waiting for a resource that you have earlier exhausted. If you're out of some space somewhere, you want to make sure that you deal with that issue. ENOSPC generally means you are out of...something.
A couple of random ideas:
I am not an expert on the PHP implementation, but I'd try to avoid calling sem_get() each time you want the semaphore. Store the handle instead. It may be that some resource is associated with each call to sem_get, and that is where you're running out of space.
I'd make sure to check your error returns on sem_get(). It's a code snippet, but if you were to fail to get the sema4, you would get inconsistent results when trying to sem_op() it (perhaps EINTR makes sense)
After posting this question I noticed that I misread the code as errno == EINTR and jumped into conclusion. So as bog has pointed out, the error is ENOSPC and not EINTR. After some digging I located the reason for ENOSPC. The number of undo buffers were getting exhausted. I have increased the number of semmnu and now the code is running with out issues. I have used semmni*semmsl as the value of semmnu