Git Product home page Git Product logo

Comments (5)

rfuchs avatar rfuchs commented on August 25, 2024

I can't confirm that.

Jul 20 14:03:49.939266 spce rtpengine[21342]: DEBUG: [«797ebf125a8325fb»]: [control] Dump for 'delete' from 127.0.0.1:45360: «{ "supports": [ "load limit" ], "call-id": "797ebf125a8325fb", "received-from": [ "IP4", "127.0.0.1" ], "from-tag": "24cafa6a4efc9a66", "command": "delete" }»
Jul 20 14:03:49.939284 spce rtpengine[21342]: INFO: [«797ebf125a8325fb»]: [core] Scheduling deletion of call branch '«24cafa6a4efc9a66»' (via-branch '«»') in 30 seconds
Jul 20 14:03:49.939290 spce rtpengine[21342]: INFO: [«797ebf125a8325fb»]: [core] Scheduling deletion of call branch '«857c9e1e-fd71-49e1-a3f8-6d3943089fb0»' (via-branch '«z9hG4bK3395.0ec0e13a6564cd6dedf330af7d2f8af2.0»') in 30 seconds
Jul 20 14:03:49.939320 spce rtpengine[21342]: INFO: [«797ebf125a8325fb»]: [core] Scheduling deletion of entire call in 30 seconds
Jul 20 14:03:49.939334 spce rtpengine[21342]: INFO: [«797ebf125a8325fb»]: [control] Replying to 'delete' from 127.0.0.1:45360 (elapsed time 0.000054 sec)
...
Jul 20 14:04:19.141362 spce rtpengine[21342]: INFO: [«797ebf125a8325fb»]: [core] Final packet stats:
Jul 20 14:04:19.141376 spce rtpengine[21342]: INFO: [«797ebf125a8325fb»]: [core] --- Tag '«24cafa6a4efc9a66»' (label 'caller'), created 0:40 ago for branch '«»'
Jul 20 14:04:19.141382 spce rtpengine[21342]: INFO: [«797ebf125a8325fb»]: [core] ---     subscribed to '«857c9e1e-fd71-49e1-a3f8-6d3943089fb0»'
Jul 20 14:04:19.141393 spce rtpengine[21342]: INFO: [«797ebf125a8325fb»]: [core] ---     subscription for '«857c9e1e-fd71-49e1-a3f8-6d3943089fb0»'
...

from rtpengine.

kdanderso avatar kdanderso commented on August 25, 2024

I've run some more tests this morning, and still cannot get the timer to delete the call. If I checkout and build 2e4dec1 (the commit before the timer refactorization), the timer works. But checking out and building c34f3e6 does not work. I see the log messages you show above for scheduling deletion and Replying to 'delete', but never see the Final packet stats and following messages.

Do you have any suggestions for what I can do to try to isolate why the timer isn't running on my system?

Thank you.

from rtpengine.

rfuchs avatar rfuchs commented on August 25, 2024

You can use ps -eLc to get a list of all individual threads. First column is process ID, second one is thread ID. The thread responsible for killing calls should be labelled "kill calls" but might just be labelled "rtpengine" (that has just been fixed today). It should be near the top of the list (third one for me).

root@spce:~# ps -eLc
    PID     LWP CLS PRI TTY          TIME CMD
...
    813     813 TS   19 ?        00:00:01 rtpengine
    813    1150 TS   19 ?        00:00:00 DTLS refresh
    813    1151 TS   19 ?        00:00:00 kill calls       <-------
    813    1159 TS   19 ?        00:00:00 signals
    813    1161 TS   19 ?        00:00:00 release socks
...

You can attach an strace to just the thread ID to see what it's doing. With no calls running you should just see it waking up once every second:

root@spce:~# strace -p 1151
strace: Process 1151 attached
restart_syscall(<... resuming interrupted read ...>) = 0
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=1, tv_nsec=0}, 0x7f827b1dbf40) = 0
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=1, tv_nsec=0}, 0x7f827b1dbf40) = 0
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=1, tv_nsec=0}, 0x7f827b1dbf40) = 0
...

With a call running, once media forwarding happens in kernel, you should see it reading from the kernel interface to update the stats:

clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=1, tv_nsec=0}, 0x7f827b1dbf40) = 0
read(4, "\v\0\0\0\2\0\0\0\177\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0:\212\0\0\0\0\0\0"..., 1232) = 1232
read(4, "\v\0\0\0\2\0\0\0\300\250\1\247\0\0\0\0\0\0\0\0\0\0\0\0\356\221\0\0\0\0\0\0"..., 1232) = 1232
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=1, tv_nsec=0}, 0x7f827b1dbf40) = 0
read(4, "\v\0\0\0\2\0\0\0\177\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0:\212\0\0\0\0\0\0"..., 1232) = 1232
read(4, "\v\0\0\0\2\0\0\0\300\250\1\247\0\0\0\0\0\0\0\0\0\0\0\0\356\221\0\0\0\0\0\0"..., 1232) = 1232
clock_nanosleep(CLOCK_REALTIME, 0, {tv_sec=1, tv_nsec=0}, 0x7f827b1dbf40) = 0

And finally, when the call is eventually deleted, you should see it printing some log messages and releasing the sockets from the poller:

write(2, "INFO: [\302\2532706799b038e2962\302\273]: [c"..., 154) = 154
write(2, "INFO: [\302\2532706799b038e2962\302\273]: [c"..., 115) = 115
read(4, "\f\0\0\0\2\0\0\0\177\0\0\1\0\0\0\0\0\0\0\0\0\0\0\0:\212\0\0\202\177\0\0"..., 1232) = 1232
write(2, "INFO: [\302\2532706799b038e2962\302\273]: [c"..., 119) = 119
read(4, "\f\0\0\0\2\0\0\0\300\250\1\247\0\0\0\0\0\0\0\0\0\0\0\0\356\221\0\0\202\177\0\0"..., 1232) = 1232
write(2, "INFO: [\302\2532706799b038e2962\302\273]: [c"..., 119) = 119
read(4, "\f\0\0\0\2\0\0\0\300\250\1\247\0\0\0\0\0\0\0\0\0\0\0\0\357\221\0\0\202\177\0\0"..., 1232) = 1232
epoll_ctl(5, EPOLL_CTL_DEL, 11, NULL)   = 0
epoll_ctl(5, EPOLL_CTL_DEL, 12, NULL)   = 0
epoll_ctl(5, EPOLL_CTL_DEL, 13, NULL)   = 0

from rtpengine.

kdanderso avatar kdanderso commented on August 25, 2024

I cloned the latest repository to make sure I had the fix for the thread names. After building, the "DTLS refresh" and "kill calls" threads do not show up in the process list returned by ps. I added debug messages to thread_looper_helper() to try to figure out what was happening. I'm seeing that those two threads never make it any further than the first call to nanosleep(). Sometimes they end earlier. It looks to me like something is killing those threads, but I don't know why or what would be doing so.

Since DTLS init and kill call are the first two threads created, I wondered if there was a startup timing issue. Looking at create_everything() in main.c, I see that they are done very early in the initialization. On a whim, I moved the call to call_init() down to just after the daemonize() and wpidfile() calls. With that change, the kill calls thread continues to run and is able to delete calls using the timer.

I assume that dtls_timer() and call_init() need to be done early in the initialization process, so moving call_init() as I have done isn't appropriate. However, it does seem that there is some sort of timing issue going on in my system that is causing those two threads to die.

Please advise if there is anything else I can do, or if this is enough information to find a solution.

Thanks.

from rtpengine.

rfuchs avatar rfuchs commented on August 25, 2024

Ah yes, forking to background is the problem, as the exit() shuts down the threads as well. And under systemd it doesn't fork so we never saw that. Thanks for the assistance.

from rtpengine.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.