### Description
### Troubleshooting
By executing an external script using exec_cmd function I'm getting the following error:
``failed. exit_status=13, errno=11: Resource temporarily unavailable``
This is happening intermittently, sometimes it's working fine, but sometimes I see this error in the log file. After looking in the debug log file I found that for some reason the exit code for the executed command is not 0 (ki_exec_cmd(): execution return code: 1), that's why this function is complaining (I guess).
What is weird that this is not happening permanently, it's about 2 cases from 5, and by running the same command manually - every time I'm getting success, all the time exit code is 0. (I'm running the same command with the same user like kamailio is running)
Replacing exec_cmd with exec_avp - I didn't notice this issue.
#### Debugging Data
```
2376cc5b10f549@192.168.0.1:5060} exec [exec_mod.c:278]: ki_exec_cmd(): executing [nice -20 /usr/local/bin/cmd arg1 arg2
2376cc5b10f549@192.168.0.1:5060} dialog [dlg_hash.c:1069]: dlg_unref_helper(): unref dlg 0x7fd643b32398 with 1 -> 4
376cc5b10f549@192.168.0.1:5060} <script>: [From=sip:+123456789@company.net, To Domain=company.net, R-URI=sip:+987654321@192.168.0.1:5060]
2376cc5b10f549@192.168.0.1:5060} <core> [main.c:905]: sig_usr(): SIGCHLD received: we do not worry about grand-children
2376cc5b10f549@192.168.0.1:5060} exec [exec_mod.c:282]: ki_exec_cmd(): execution return code: 1
2376cc5b10f549@192.168.0.1:5060} <core> [core/action.c:1598]: run_actions(): alert - action [corefunc (16)] cfg [/etc/kamailio-dev/conf.d/routes.cfg:1567] took too long [780373 us]
2376cc5b10f549@192.168.0.1:5060} dialog [dlg_hash.c:877]: internal_get_dlg(): ref dlg 0x7fd643b32398 with 1 -> 5
```
### Possible Solutions
Use exec_avp instead
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
version: kamailio 5.4.1 (x86_64/linux) a6cb74
```
* **Operating System**:
```
CentOS 7 x64
Linux k3-core1.nuacom.eqx 3.10.0-1127.8.2.el7.x86_64 #1 SMP Tue May 12 16:57:42 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
```
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2538
I’m doing some testing on Dispatcher in order to prepare it for HA setups with floating IPs on Kamailio version 5.4.1.
In this scenario my calls must be sent to SET with the ID 2 :
> SET: {
ID: 2
TARGETS: {
DEST: {
URI: sip:GW_IP:5061
FLAGS: AX
PRIORITY: 0
ATTRS: {
BODY: duid=TB_MG03;socket=SOCKET_IP_1:5060
DUID: TB_MG03
MAXLOAD: 0
WEIGHT: 0
RWEIGHT: 0
SOCKET: SOCKET_IP_1:5060
SOCKNAME:
OBPROXY:
}
RUNTIME: {
DLGLOAD: 0
}
}
DEST: {
URI: sip:GW_IP:5061
FLAGS: AX
PRIORITY: 0
ATTRS: {
BODY: duid=TB_MG02;socket=SOCKET_IP_2:5060
DUID: TB_MG02
MAXLOAD: 0
WEIGHT: 0
RWEIGHT: 0
SOCKET: SOCKET_IP_2:5060
SOCKNAME:
OBPROXY:
}
RUNTIME: {
DLGLOAD: 0
}
}
}
}
As you can see, both gateways have the same URI but they have different sockets. In this scenario i tried to make a bunch of calls with this set as destination but all calls ended being delivered with socket "SOCKET_IP_2:5060" as oposed to doing a load balancing. This isn’t a real scenario since i wouldn’t want load balance for the same destination, but the objective is to show you the balance feature failing in this conditions, in order to help you debug the issue.
After that i tried a different scenario. This time i disabled the destination with DUID TB_MG02 and socket SOCKET_IP_2:5060 and made the same test.
> SET: {
ID: 2
TARGETS: {
DEST: {
URI: sip:GW_IP:5061
FLAGS: AX
PRIORITY: 0
ATTRS: {
BODY: duid=TB_MG03;socket=SOCKET_IP_1:5060
DUID: TB_MG03
MAXLOAD: 0
WEIGHT: 0
RWEIGHT: 0
SOCKET: SOCKET_IP_1:5060
SOCKNAME:
OBPROXY:
}
RUNTIME: {
DLGLOAD: 0
}
}
DEST: {
URI: sip:GW_IP:5061
FLAGS: DX
PRIORITY: 0
ATTRS: {
BODY: duid=TB_MG02;socket=SOCKET_IP_2:5060
DUID: TB_MG02
MAXLOAD: 0
WEIGHT: 0
RWEIGHT: 0
SOCKET: SOCKET_IP_2:5060
SOCKNAME:
OBPROXY:
}
RUNTIME: {
DLGLOAD: 0
}
}
}
}
In this test all the calls ended up being delivered with SOCKET_IP_2 as the socket. This time no load balance was made and a disabled destination was used.
I’ve tried reversing the order of the destinations in the configuration and it now chooses socket SOCKET_IP_1 all the time.
If both destinations have different URIs none of this problems happen, only with two destinations with same address but different sockets.
Here are my dispatcher parameters, let me know if there is some config wrong :
modparam("dispatcher", "flags", 2) // Failover support is enabled
modparam("dispatcher", "ds_ping_method", "OPTIONS")
modparam("dispatcher", "ds_hash_size", 8)
modparam("dispatcher", "db_url", DBURL)
modparam("dispatcher", "table_name", "TBK_DISPATCHER")
modparam("dispatcher", "setid_col", "TBK_NapGroupId")
modparam("dispatcher", "destination_col", "TBK_NapPeer")
modparam("dispatcher", "flags_col", "TBK_NapState")
modparam("dispatcher", "priority_col", "TBK_NapPriority")
modparam("dispatcher", "attrs_col", "TBK_NapAttrs")
modparam("dispatcher", "ds_probing_mode", 3)
modparam("dispatcher", "ds_ping_interval", 10)
modparam("dispatcher", "ds_probing_threshold", 2)
modparam("dispatcher", "ds_inactive_threshold", 2)
modparam("dispatcher", "ds_ping_reply_codes", "code=200;code=484;code=404")
modparam("dispatcher", "ds_db_extra_attrs", "socket=TBK_Sap")
modparam("dispatcher", "ds_ping_from", "sip:PeerProbing@peer.probing")
What do you think might be the problem here? If you need any more info please let me know. HA setup is a really important feature for us to move forward and as such we need to assure that we use the correct socket.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2527
Hello,
Kamailio SIP Server v5.3.7 stable release is out.
This is a maintenance release of the latest stable branch, 5.3, that
includes fixes since the release of v5.3.6. There is no change to
database schema or configuration language structure that you have to do
on previous installations of v5.3.x. Deployments running previous v5.3.x
versions are strongly recommended to be upgraded to v5.3.7.
Note that 5.3 is the second last stable branch, still officially maintained
by Kamailio development team. The latest stable branch is 5.4, with
v5.4.2 being release out of it.
For more details about version 5.3.7 (including links and guidelines to
download the tarball or from GIT repository), visit:
* https://www.kamailio.org/w/2020/11/kamailio-v5-3-7-released/
RPM, Debian/Ubuntu packages will be available soon as well.
Many thanks to all contributing and using Kamailio!
Cheers,
Daniel
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda