Author Topic: [fix] Wrong killing of extmodule  (Read 474 times)

andr04

  • Newbie
  • *
  • Posts: 17
    • View Profile
[fix] Wrong killing of extmodule
« on: May 09, 2017, 06:40:04 PM »
Some time ago I said about the bug of terminating external module. I've fixed it and changed the logic of quiting from external module as follows.

If exit is initiated from external module it just close their stdout and finish running. Yate as soon as get EOF trying to check is pid terminated or not and waiting up to m_timeout. If EOF was get from socket nothing to wait.

If exit initiated from Yate the engine send to external module %%<quit message and waiting EOF/pid termination as described above.

%%>quit from external module to Yate I've make redundant. But it's possible to interpret it as a "kill me" signal without waiting and without %%<quit as a reply. Let me know how it must be.

The approach let external modules to handle quit messages. It is useful for example if external module registers external lines through user.login message: it's may be important to unregister lines on module quiting (operation=logout).

I'm new in Yate and would like how can I share described improvements? How can I commit it and to know is it a needed feature?

marian

  • Sr. Member
  • ****
  • Posts: 384
    • View Profile
Re: [fix] Wrong killing of extmodule
« Reply #1 on: May 10, 2017, 12:56:08 AM »
Hi,
What is the purpose of this improvement?

If an external script wants to know when yate is going to stop it may install a handler for engine.stop message.

andr04

  • Newbie
  • *
  • Posts: 17
    • View Profile
Re: [fix] Wrong killing of extmodule
« Reply #2 on: May 10, 2017, 06:45:44 AM »
It's 2 improvements: waiting of termination and notification about starting termination. External scripts can be large and complicated. Not only about Yate going to stop but about the external module going to stop it's important to know to close their resources and unregister their lines and accounts (notify SIP clients about loging out). Another case -- channel/playrec external modules started and terminated by Yate for every call and it is also important not only to get notification about quiting but to close their resources properly as well.

Killing by SIGTERM is present on exceptions and wrong behavior.
« Last Edit: May 10, 2017, 07:40:31 AM by andr04 »

andr04

  • Newbie
  • *
  • Posts: 17
    • View Profile
Re: [fix] Wrong killing of extmodule
« Reply #3 on: May 11, 2017, 09:43:25 AM »
Any suggestions?

marian

  • Sr. Member
  • ****
  • Posts: 384
    • View Profile
Re: [fix] Wrong killing of extmodule
« Reply #4 on: May 12, 2017, 08:09:47 AM »
For more info on external module protocol see:
http://docs.yate.ro/wiki/External_Module
http://docs.yate.ro/wiki/External_module_command_flow

For channel scripts you may install message handlers to check termination (see chan.disconnected): when peer channel is hung up your channel script will send a chan.disconnected message: you may catch it

andr04

  • Newbie
  • *
  • Posts: 17
    • View Profile
Re: [fix] Wrong killing of extmodule
« Reply #5 on: May 15, 2017, 04:17:35 AM »
Yes, I use extmodule command flow but it must (can) be improved.
Quote
If an external script wants to know when yate is going to stop it may install a handler for engine.stop message.
Quote
For channel scripts you may install message handlers to check termination (see chan.disconnected)

Why do you think 2 different methods better than 1 in my solution? In my view it looks like a crutch. First one (engine.stop message) doesn't cover script restarting from CLI. Second one (chan.disconnected message) doesn't work at all due to CallEndpoint destruction. I installed handler for it (extmodule.cpp from 5.5.0 version without changes), but it doesn't work:
Code: [Select]
2017-05-15_09:48:27.212239 <sip:INFO> 'udp:0.0.0.0:5060' received 418 bytes SIP message from 85.142.148.80:5060 [0x140add0]
------
BYE sip:200@37.140.188.160:5060 SIP/2.0
Via: SIP/2.0/UDP 85.142.148.80:5060;rport;branch=z9hG4bKPj11500195-5795-455d-8971-2d13f3b0faf1
From: "laptop" <sip:laptop@talk37.ru>;tag=97bbbc5f-41bb-4abe-a293-775d02e33440
To: <sip:200@37.140.188.160>;tag=1893302431
Call-ID: b98b4e73-cd84-4a69-b4dc-a1430ce5af6a
CSeq: 32719 BYE
Reason: Q.850;cause=16
Max-Forwards: 70
User-Agent: ruVoIP.net PBX
Content-Length:  0

------
2017-05-15_09:48:27.222087 <sip:INFO> 'udp:0.0.0.0:5060' sending code 100 0x7f3590012180 to 85.142.148.80:5060 [0x140add0]
------
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 85.142.148.80:5060;rport=5060;branch=z9hG4bKPj11500195-5795-455d-8971-2d13f3b0faf1;received=85.142.148.80
From: "laptop" <sip:laptop@talk37.ru>;tag=97bbbc5f-41bb-4abe-a293-775d02e33440
To: <sip:200@37.140.188.160>;tag=1893302431
Call-ID: b98b4e73-cd84-4a69-b4dc-a1430ce5af6a
CSeq: 32719 BYE
Server: YATE/5.5.0
Content-Length: 0

------
2017-05-15_09:48:27.222179 <yrtp:INFO> YRTPWrapper::terminate() [0x7f358c011fc0]
2017-05-15_09:48:27.222205 >>> DataTranslator::detachChain(0x7f358c012610,0x7f358c014190)
2017-05-15_09:48:27.222212   >>> DataTranslator::detachChain(0x7f358c012610,0x7f3590012820)
2017-05-15_09:48:27.222216   <<< DataTranslator::detachChain
2017-05-15_09:48:27.222225 <<< DataTranslator::detachChain
2017-05-15_09:48:27.222229 >>> DataTranslator::detachChain(0x7f358c011840,0x7f358c017340)
2017-05-15_09:48:27.222234   >>> DataTranslator::detachChain(0x7f358c011840,0x7f3590013950)
2017-05-15_09:48:27.222238   <<< DataTranslator::detachChain
2017-05-15_09:48:27.222242 <<< DataTranslator::detachChain
2017-05-15_09:48:27.222253 <ALL> Cleaning up RTP 0x7f358c012170 [0x7f358c011fc0]
2017-05-15_09:48:27.222333 <ALL> ExtModChan::disconnected() '(null)' [0x7f358c014040]
2017-05-15_09:48:27.222345 <ALL> ExtModConsumer::~ExtModConsumer() [0x7f358c014190] total=53120
2017-05-15_09:48:27.222358 >>> ExtModChan::~ExtModChan() [0x7f358c014040]
2017-05-15_09:48:27.222374   <ALL> ExtModReceiver::die() pid=9064 dead=no [0x7f358c013d80]
2017-05-15_09:48:27.222382   <ALL> ExtModReceiver::die() waiting for pid=9064 to die [0x7f358c013d80]
2017-05-15_09:48:27.228405   <INFO> ExtModReceiver::die() pid=9064 did not exit? [0x7f358c013d80]
2017-05-15_09:48:27.232148   <ExtModule:WARN> Read error 9 on 0x7f35840011f0 [0x7f358c013d80]
2017-05-15_09:48:27.232287   <WARN> Process 9064 has not exited on closing stdin - we'll kill it
2017-05-15_09:48:27.232379   <WARN> Process 9064 has still not exited yet?
2017-05-15_09:48:27.233520   <ALL> ExtModSource [0x7f358c011840] end of data total=16000
2017-05-15_09:48:27.233550   <ALL> ExtModSource::~ExtModSource() [0x7f358c011840] total=16000
2017-05-15_09:48:27.233581   <ALL> ExtModReceiver::~ExtModReceiver() pid=0 [0x7f358c013d80]
2017-05-15_09:48:27.233589   <ALL> ExtModReceiver::die() pid=0 dead=yes [0x7f358c013d80]
2017-05-15_09:48:27.233595 <<< ExtModChan::~ExtModChan()
2017-05-15_09:48:27.233654 <sip:INFO> 'udp:0.0.0.0:5060' sending code 200 0x7f3590013950 to 85.142.148.80:5060 [0x140add0]
------
SIP/2.0 200 OK
Via: SIP/2.0/UDP 85.142.148.80:5060;rport=5060;branch=z9hG4bKPj11500195-5795-455d-8971-2d13f3b0faf1;received=85.142.148.80
From: "laptop" <sip:laptop@talk37.ru>;tag=97bbbc5f-41bb-4abe-a293-775d02e33440
To: <sip:200@37.140.188.160>;tag=1893302431
Call-ID: b98b4e73-cd84-4a69-b4dc-a1430ce5af6a
CSeq: 32719 BYE
P-RTP-Stat: PS=60,OS=7500,PR=166,OR=26560,PL=0
Server: YATE/5.5.0
Allow: ACK, INVITE, BYE, CANCEL, REGISTER, REFER, OPTIONS, INFO
Content-Length: 0

------

And I believe Process 9064 has not exited on closing stdin - we'll kill it -- it's not what we want to see in log on the normal case.

My solution allows to write extmodules in a common case more likely to cpp modules: you can do some operations on module constructor and module destructor as well. Moreover I fixed catching chan.disconnected message as well.