As background I’m running 1.8.5. At any rate I had a situation the other day where some cleanup and bookkeeping that is done on hangup failed to occur. Immediately preceding the error was a System call to a script. Below are the relevant logging materials:
After that last line, that is the end for channel SIP/customer-proxy-0016de93. I’ve been unable to find anything definitive when I’ve searched around for similar issues.
Is there any more info that can be derived from “asterisk.c: Fork failed: Unknown error 513”? There was nothing off or malformed about the script args in the shell command, so I am wondering if it is possibly an issue with the System command itself.
More specifically what do app_system and features have to do with this? I’m not sure what app_system does, but I am pretty sure Parking had nothing to do with this.
Anyone with any insights into this, I’d greatly appreciate some feedback (I can supply extra details if need be). Thanks.
I’m running Cent 5.8 Final, and I don’t think any POSIX systems generate negative PIDs.
Are you saying that the “Unknown error 513” resulted from a bad errno value from fork/vfork. Does this mean the call to '/some/script “arg1” “arg2” returned negative or the fork/vfork call in asterisk.c returned negative?
Thanks David. Sorry to be tedious, but I have one last question. Is it possible that somehow there was a problem in the logging, like maybe code Permission Denied code 13 was written to a buffer that had other stuff in it already?
I’m just trying to sort out every possible piece that could have caused “errno 513” to appear in my logging. And just regarding your opinion, do you think it is more likely for slightly wonking logging to be the culprit, or the fork/vfork application?
It might be something to do with the pthreads environment.
Fork would typically fail if the process had exceeded the maximum number of processes or was out of memory. If I read the man page correctly, that could include cases where there was insufficient real memory at the time of the request, even though the system was not out of virtual memory.
Note that this error appears to be happening before the exec, so the script is irrelevant.