Clean way to stop a device server
|
|
---|---|
Hi Tangoers, For testing purposes I am starting a number of device servers programmatically. The servers are started as separate processes and I am interacting with them via DeviceProxies. Things basically work with one little exception: when I am done with my tests and want to shut the servers down (I am doing this by calling adminDevice.Kill()), some of the server processes do not stop but seem to hang. I noticed that the problematic servers are the ones that themselves subscribe to change events distributed by other devices. I tried to unsubscribe from the events system in the delete_device method, but this did not help. My question: is there some kind of procedure that needs to be performed in the delete_device method so that the device server can cleanly shut down? Best regards, Csaba p.s. I am attaching a Python script that demonstrates the problem. What I expect from this script is to terminate after the tests are done. This does not happen because the process of DeviceB does not terminate. If I comment out the code doing the event subscription (line 113) , the script executes as expected. p.s.2: The test script needs a Tango database to execute. First I tried to write it so that it works with no-db devices, but then I could not get the change events working. Is this a bug, or I made a mistake somewhere? |
|
|
---|---|
Hi Csaba, Sorry for this late answer (Some holidays in France…) We made some tests here to try to re-produce your issue but we can't. We have tried in C++ using the admin device Kill command and it killed all we wanted it to kill We have tried your script as well without problems. It always terminated fine. We have used PyTango 8.1.6. Which release are you using? About your PS2 (Events with no-db devices), you are right. There was a bug there which is now fixed and which will be included in next C++ Tango release. Hoping this help Emmanuel |
|
|
---|---|
Hi Emmanuel, Thank you for taking the time to test this. And I am sorry for forgetting the version info: I am running PyTango 8.1.5 with Tango 8.1.2c on Debian Jessie. And a further reason to apologize: the script I posted had a bug, which resulted in the event subscription to fail, so it could not demonstrate the problem. I am attaching a fixed version of the script. We have tested this with PyTango 8.1.6 and also on Ubuntu - the problem persists for us. Best regards, Csaba ps: having events working with nodb devices is great news! |
|
|
---|---|
Hi Csaba Here are the outputs I get when I run your script using PyTango 8.1.6 on a debian 6 host: python test.py server DeviceA/_test_csaba found in DB, deleting it registered device _test_csaba/DeviceA/01 for server DeviceA/_test_csaba server DeviceB/_test_csaba found in DB, deleting it registered device _test_csaba/DeviceB/01 for server DeviceB/_test_csaba procex[721]: [ctl] Started python -c import PyTango;from test import DeviceA;serverArgs='DeviceA _test_csaba -v';PyTango.server.run([DeviceA],serverArgs.split()) procex[721]: Failed to import EventChannelFactory notifd/factory/pastis.esrf.fr from the Tango database DeviceA(_test_csaba/devicea/01) state is ON procex[861]: [ctl] Started python -c import PyTango;from test import DeviceB;serverArgs='DeviceB _test_csaba -v';PyTango.server.run([DeviceB],serverArgs.split()) procex[861]: Failed to import EventChannelFactory notifd/factory/pastis.esrf.fr from the Tango database DeviceB(_test_csaba/deviceb/01) state is ON pb.events.length=1 pb.events.length=2 Stopping servers procex[721]: device _test_csaba/DeviceA/01 inited procex[721]: Ready to accept request procex[721]: ZmqEventSupplier::push_event(): called for attribute state procex[721]: device _test_csaba/DeviceA/01 deleted procex[721]: [ctl] Terminated procex[861]: event received procex[861]: device _test_csaba/DeviceB/01 inited procex[861]: Ready to accept request procex[861]: event received procex[861]: device _test_csaba/DeviceB/01 deleted procex[861]: cancelled subscription 1 procex[861]: [ctl] Terminated End of script pastis:/segfs/tango/tmp % Isn't it correct? Emmanuel |
|
|
---|---|
Hi Emmanuel, The output you got is the perfect one. I get something similar with one "Terminated" missing: server DeviceA/_test_csaba found in DB, deleting it registered device _test_csaba/DeviceA/01 for server DeviceA/_test_csaba server DeviceB/_test_csaba found in DB, deleting it registered device _test_csaba/DeviceB/01 for server DeviceB/_test_csaba procex[28312]: [ctl] Started python -c import PyTango;from killtest import DeviceA;serverArgs='DeviceA _test_csaba -v';PyTango.server.run([DeviceA],serverArgs.split()) procex[28312]: Failed to import EventChannelFactory notifd/factory/pc960-t3610 from the Tango database procex[28312]: device _test_csaba/DeviceA/01 inited procex[28312]: Ready to accept request DeviceA(_test_csaba/devicea/01) state is ON procex[28338]: [ctl] Started python -c import PyTango;from killtest import DeviceB;serverArgs='DeviceB _test_csaba -v';PyTango.server.run([DeviceB],serverArgs.split()) procex[28338]: Failed to import EventChannelFactory notifd/factory/pc960-t3610 from the Tango database procex[28338]: event received procex[28338]: device _test_csaba/DeviceB/01 inited procex[28338]: Ready to accept request DeviceB(_test_csaba/deviceb/01) state is ON pb.events.length=1 procex[28338]: event received pb.events.length=2 Stopping servers procex[28338]: device _test_csaba/DeviceB/01 deleted procex[28338]: cancelled subscription 1 procex[28312]: device _test_csaba/DeviceA/01 deleted procex[28312]: [ctl] Terminated End of script Another difference is the "ZmqEventSupplier::push_event(): called for attribute state" message that you get, but I do not. Does that indicate some difference in the Tango native libraries we use? Csaba |
|
|
---|---|
Hi Csaba, Which release of Tango C++ library do you use? How did you get it? From the source distribution or from the Ubuntu/Debian repo? Do you have all the patches installed? Cheers Emmanuel |
|
|
---|---|
Hi Emmanuel, I have libtango 8.1.2c+dfsg-5 from the official Debian repository. I was told that this already includes the patches. (what is probably true, since I can subscribe to change events despite of having ZMQ version 4). Best regards, Csaba |