delete_device() not called when interrupting the DS with CTRL+C
delete_device() is -apparently- not called if the server execution is interrupted with CTRL+C
See the following snippet:
from tango.server import Device
class Dummy(Device):
def init_device(self):
print("hello")
def delete_device(self):
print("goodbye")
def _run():
# register the device (only needed once, but just in case it was not done)
import tango
dev_info = tango.DbDevInfo()
dev_info.server = "Dummy/test"
dev_info._class = "Dummy"
dev_info.name = "test/dummy/1"
db = tango.Database()
db.add_device(dev_info)
# run the server
Dummy.run_server()
def _run_within_testcontext():
from tango.test_context import DeviceTestContext
with DeviceTestContext(Dummy, process=True):
pass
if __name__ == "__main__":
import sys
if sys.argv[1] == "context":
_run_within_testcontext()
else:
_run()
If I run it within the text context, I see that delete_device is called:
$ python check_delete.py context
Can't create notifd event supplier. Notifd event not available
hello
Ready to accept request
Ready to accept request
goodbye
but if I run it "normally" and I press CTR+C when it is ready, the "goodbye" message is not printed to stdout:
$ python check_delete.py test
hello
Ready to accept request
Ready to accept request
^C⏎
$
Note: this is done in a pristine conda environment created with conda create -n test -c conda-forge pytango:
$ conda list
# packages in environment at /home/cpascual/miniconda/envs/test:
#
# Name Version Build Channel
_libgcc_mutex 0.1 conda_forge conda-forge
_openmp_mutex 4.5 1_gnu conda-forge
boost 1.74.0 py39h5472131_3 conda-forge
boost-cpp 1.74.0 hc6e9bd1_2 conda-forge
bzip2 1.0.8 h7f98852_4 conda-forge
ca-certificates 2020.12.5 ha878542_0 conda-forge
certifi 2020.12.5 py39hf3d152e_1 conda-forge
cpptango 9.3.4 hf7cf922_3 conda-forge
icu 68.1 h58526e2_0 conda-forge
ld_impl_linux-64 2.35.1 hea4e1c9_2 conda-forge
libblas 3.9.0 8_openblas conda-forge
libcblas 3.9.0 8_openblas conda-forge
libffi 3.3 h58526e2_2 conda-forge
libgcc-ng 9.3.0 h2828fa1_18 conda-forge
libgfortran-ng 9.3.0 hff62375_18 conda-forge
libgfortran5 9.3.0 hff62375_18 conda-forge
libgomp 9.3.0 h2828fa1_18 conda-forge
liblapack 3.9.0 8_openblas conda-forge
libopenblas 0.3.12 pthreads_h4812303_1 conda-forge
libsodium 1.0.18 h36c2ea0_1 conda-forge
libstdcxx-ng 9.3.0 h6de172a_18 conda-forge
lz4-c 1.9.3 h9c3ff4c_0 conda-forge
ncurses 6.2 h58526e2_4 conda-forge
numpy 1.20.1 py39hdbf815f_0 conda-forge
omniorb 4.2.4 py39hff7568b_2 conda-forge
openssl 1.1.1j h7f98852_0 conda-forge
pip 21.0.1 pyhd8ed1ab_0 conda-forge
pytango 9.3.3 py39hbcdfc36_1 conda-forge
python 3.9.2 hffdb5ce_0_cpython conda-forge
python_abi 3.9 1_cp39 conda-forge
readline 8.0 he28a2e2_2 conda-forge
setuptools 49.6.0 py39hf3d152e_3 conda-forge
six 1.15.0 pyh9f0ad1d_0 conda-forge
sqlite 3.34.0 h74cdb3f_0 conda-forge
tk 8.6.10 h21135ba_1 conda-forge
tzdata 2021a he74cb21_0 conda-forge
wheel 0.36.2 pyhd3deb0d_0 conda-forge
xz 5.2.5 h516909a_1 conda-forge
zeromq 4.3.4 h9c3ff4c_0 conda-forge
zlib 1.2.11 h516909a_1010 conda-forge
zstd 1.4.9 ha95c52a_0 conda-forge
Not sure if this is a bug or an expected behaviour, but in taurus-org/taurus#982 (closed) @reszelaz indicates that this used to behave differently.