[OpenSIPS-Users] Critical:core:anchor_lump: offset exceeds message size (1033 > 1000), aborting -- exited by signal 6
fabio4prez
bobby.smith at gmail.com
Mon Mar 23 21:50:07 CET 2009
Hello all,
<br><br>We're running Opensips in a production environment with about 10,000 users. We're currently running in a Registrar/Stateless proxy configuration -- very basic setup.
<br><br>Anyways, to the point. Currently, at random points throughout the day, opensips will stop running and the following will show up in the log:
<br><br>Mar 23 15:04:35 serbox2 /sbin/opensips[19181]: ERROR:registrar:update_contacts: invalid cseq for aor <70154>
<br>Mar 23 15:04:35 serbox2 /sbin/opensips[19178]: ERROR:registrar:update_contacts: invalid cseq for aor <vh27126>
<br>Mar 23 15:04:35 serbox2 /sbin/opensips[19180]: ERROR:registrar:update_contacts: invalid cseq for aor <70154>
<br>Mar 23 15:04:36 serbox2 /sbin/opensips[19181]: CRITICAL:core:anchor_lump: offset exceeds message size (1033 > 1000) aborting...
<br>Mar 23 15:04:36 serbox2 /sbin/opensips[19178]: CRITICAL:core:anchor_lump: offset exceeds message size (1033 > 1000) aborting...
<br>Mar 23 15:04:40 serbox2 /sbin/opensips[19180]: CRITICAL:core:anchor_lump: offset exceeds message size (1033 > 1000) aborting...
<br>Mar 23 15:04:48 serbox2 /sbin/opensips[19177]: INFO:core:handle_sigs: child process 19181 exited by a signal 6
<br>Mar 23 15:04:48 serbox2 /sbin/opensips[19177]: INFO:core:handle_sigs: core was generated
<br>Mar 23 15:04:48 serbox2 /sbin/opensips[19177]: INFO:core:handle_sigs: terminating due to SIGCHLD
<br>Mar 23 15:04:48 serbox2 /sbin/opensips[19179]: INFO:core:sig_usr: signal 15 received
<br>Mar 23 15:04:48 serbox2 /sbin/opensips[19182]: INFO:core:sig_usr: signal 15 received
<br>Mar 23 15:04:48 serbox2 /sbin/opensips[19183]: INFO:core:sig_usr: signal 15 received
<br>Mar 23 15:05:24 serbox2 opensips: WARNING:core:fix_socket_list: could not rev. resolve XXX.XXX.XXX.XXX
<br><br>I'm not certain that this is a route script issue. It seems like a message header that isn't present is trying to be parsed or something along those lines. In trying to track this issue down, but would like a few pointers as to where to be looking.
<br><br>First, we've currently set the number of forks at 6 and the private memory per process to 32 MB. We're also using 512 MB of "shared" memory.
<br><br>A) Are there any recommendations as to memory requirements for the amount of users/subscriber base? Again, we process somewhere around 2 million registrations alone in an hour, and just statelessly forward requests unless they're destined for a UAC, where we do a location lookup and then forward to the handset.
<br><br>I haven't really found any core statistics or guidelines for memory parameters set. If there is any better documentation on this, I'd greatly appreciate a link.
<br><br>B) Here's the basic contents of our route script (where the ip addresses have been changed to *.domain for security purposes)
<br><br>route
<br>{
<br> if (!mf_process_maxfwd_header("10"))
<br> {
<br> sl_send_reply("483","Too Many Hops");
<br> exit;
<br> }
<br><br> if (!is_method("REGISTER|MESSAGE"))
<br> {
<br> if(nat_uac_test("19"))
<br> {
<br> record_route(";nat=yes");
<br> }
<br> else
<br> {
<br> record_route();
<br> }
<br> }
<br><br> if (is_method("REGISTER"))
<br> {
<br> if (!search("^Contact:\ +\*"))
<br> {
<br> # xlog("Contact fix $ru\n");
<br> fix_nated_register();
<br> force_rport();
<br> }
<br><br> if (!save("location"))
<br> sl_reply_error();
<br> exit;
<br> }
<br><br> if(src_ip == "sbc.domain")
<br> {
<br> rewritehost("ser.domain");
<br><br> if(!lookup("location"))
<br> {
<br> sl_send_reply("404", "Not Found");
<br> exit;
<br> }
<br><br> route(1);
<br> exit;
<br> }
<br><br> else
<br> {
<br> if(is_method("NOTIFY"))
<br> {
<br> sl_send_reply("404", "Not Found");
<br> exit;
<br> }
<br><br> rewritehost("sbc.domain");
<br> route(1);
<br> exit;
<br> }
<br>}
<br><br># --------- route[1] block -------------
<br># Handle NAT-related issues on INVITES
<br>#
<br><br>route[1]
<br>{
<br> #xlog("Beginning route $ru\n");
<br> if (is_method("INVITE"))
<br> {
<br> force_rport();
<br> fix_nated_contact();
<br> fix_nated_sdp("10");
<br> # xlog("Routing 1 inside $ru\n");
<br> forward();
<br> exit;
<br> }
<br> force_rport();
<br> fix_nated_contact();
<br><br> # xlog("Forward route $ru\n");
<br><br> if (!forward())
<br> {
<br> sl_reply_error();
<br> };
<br>}
<br><br><br><br>Is there a particular time where, for example, we're trying to fix a header that might not exist, that could cause this particular issue?
<br><br>As an FYI, we're currently running Opensips version 1.4.2, and are considering a production release to 1.4.5 tonight to see if any of these particular issues are fixed. I see also that 1.5 was released as well, is this a production worthy release?
<br><br>Lastly, we see this a lot in the logs:
<br><br>Mar 23 16:47:35 serbox2 /sbin/opensips[24586]: ERROR:registrar:update_contacts: invalid cseq for aor <vh13669>
<br>Mar 23 16:47:36 serbox2 /sbin/opensips[24586]: ERROR:registrar:update_contacts: invalid cseq for aor <vh13669>
<br><br>I've read something about Polycom user agent's attempting to reregister with the same call-id but incrimenting the cseq ID, but I also think I've read that there was a fix for the order this was looked up in in a version past 1.4.2.
<br><br>Thanks very much for any help.
--
View this message in context: http://n2.nabble.com/Critical%3Acore%3Aanchor_lump%3A-offset-exceeds-message-size-%281033-%3E-1000%29%2C-aborting----exited-by-signal-6-tp2523387p2523387.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.
More information about the Users
mailing list