<!-- Kamailio Project uses GitHub Issues only for bugs in the code or feature requests. Please use this template only for bug reports.
If you have questions about using Kamailio or related to its configuration file, ask on sr-users mailing list:
* http://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
If you have questions about developing extensions to Kamailio or its existing C code, ask on sr-dev mailing list:
* http://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev
Please try to fill this template as much as possible for any issue. It helps the developers to troubleshoot the issue.
If there is no content to be filled in a section, the entire section can be removed.
You can delete the comments from the template sections when filling.
You can delete next line and everything above before submitting (it is a comment). -->
### Description tm module writes a misleading log error that `triggers` ops alerts.
<!-- Explain what you did, what you expected to happen, and what actually happened. -->
### Troubleshooting
#### Reproduction using this partial script
``` event_route[core:worker-one-init] { async_route("DEFERRED_CLEANUP", "20"); }
route[DEFERRED_CLEANUP] { xlog("L_INFO", "processing deferred cleanup\n"); } ```
#### Log Messages <!-- Check the syslog file and if there are relevant log messages printed by Kamailio, add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site). -->
``` 2018-11-15T19:22:44.547049+00:00 apps001 kamailio[2105]: INFO: <script>: processing deferred cleanup 2018-11-15T19:22:44.554085+00:00 apps001 kamailio[2105]: ERROR: tm [t_reply.c:551]: _reply_light(): no resolved dst to send reply to ```
### Possible Solutions
i silence the error with the below patch but i'm pretty sure its not the proper way to do it.
``` diff --git a/src/modules/tm/t_reply.c b/src/modules/tm/t_reply.c index 8a95fe7..99c59db 100644 --- a/src/modules/tm/t_reply.c +++ b/src/modules/tm/t_reply.c @@ -548,7 +548,9 @@ * the chances for this increase a lot. */ if (unlikely(!trans->uas.response.dst.send_sock)) { - LM_ERR("no resolved dst to send reply to\n"); + if(is_local(trans)) { + LM_ERR("no resolved dst to send reply to\n"); + } } else { if (likely(SEND_PR_BUFFER( rb, buf, len )>=0)){ if (unlikely(code>=200 && !is_local(trans) && ``` <!-- If you found a solution or workaround for the issue, describe it. Ideally, provide a pull request with a fix. -->
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
``` version: kamailio 5.3.0-dev0 (x86_64/linux) 37bff4-dirty flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144 MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
```
* **Operating System**:
<!-- Details about the operating system, the type: Linux (e.g.,: Debian 8.4, Ubuntu 16.04, CentOS 7.1, ...), MacOS, xBSD, Solaris, ...; Kernel details (output of `uname -a`) -->
``` Linux 2.6.32-754.el6.x86_64 #1 SMP Tue Jun 19 21:26:04 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux ```
Async was not designed to work with a faked request, like the one from `event_route[core:worker-one-init]`, because it does suspend/continue of a transaction for a request that is not received from the network and not to be routed. Maybe it can be enhanced, but meanwhile look at the next alternatives to execute actions after a period of time:
* rtimer module * evrexec module
@miconda i looked at rtimer and evrexec in the first place. the problem is that we need a one time deferred execution
Closed #1727.
evrexec executes only once, you would have to do a loop or something else to continue execution. It allows to set the interval to wait before executing the route block.
With rtimer, you can use a test on a $var(...), which is initialized to 0, the set it to 1 with the first execution. At the top of the route you should do if $var(...) != 0 then return.
I also pushed a patch to async module to detect when faked msg is tried to be used and return error. I will look at other parts of code that are similar and try to enforce it there as well.
I am going to close this one here, the error is not in tm anyhow. We can discuss more on mailing list if you have a specific use case and you don't know if it is possible to do/how to do.
@miconda i'm ok with you closing this one and discussion going into mailing list.
fyi, none of the proposed uses (rtimer, evrexec) will keep you from having a `ghost` process that does nothing after 1st execution, which seems not ideal since it still using resources (memory). rtimer will keep running the event routes evrexec will never exit the process
rtimer can use the core timer, no new process created.
Also async creates processes, so if you just use it for this case, then there are ghost processes in the same way.
See also timer module, wrote by ser developers, iirc, it has a way to disable the timer task, but I am not familiar with it to say for sure.
Then, feel free to add a new feature for what you need. Just that what you reported here is not a bug and not the right fix.
yes, already agreed on closing this. thanks
-
Daniel-Constantin Mierla -
lazedo