Project

General

Profile

Bug #2248

osmo-gsm-tester: Handle CTRL+C correctly

Added by pespin about 2 months ago. Updated 27 days ago.

Status:
Resolved
Priority:
Normal
Assignee:
Target version:
-
Start date:
05/08/2017
Due date:
% Done:

100%

Spec Reference:

Description

IF you press CTRL+C, I think the standard signal is called and the process is killed. It would be nice to handle the signal and at least remove the lock on the resources and finish as good as possible.

History

#1 Updated by laforge about 1 month ago

  • Assignee deleted (Osmocom Developers)

#2 Updated by laforge about 1 month ago

  • Assignee set to osmo-gsm-tester

#3 Updated by neels about 1 month ago

  • Status changed from New to Feedback
  • Assignee changed from osmo-gsm-tester to pespin

This should be solved by https://gerrit.osmocom.org/2486 and https://gerrit.osmocom.org/2485

I often use ctrl-c abort a test gracefully. Pau, do you still have a usage where that doesn't work?

#4 Updated by pespin about 1 month ago

Yes, I still see the issue with latest master when I'm running the test (ie. nitb started). Then I CTRL+C and the resources are not freed/stopped:

# ps -ef | grep osmo
root     28959 28957 31 12:42 ?        00:00:20 python3 -u ./osmo-gsm-tester.py /var/tmp/osmo-gsm-tester/trials//trial-100 -s sms
root     28974 28959  0 12:42 ?        00:00:00 tcpdump -n -i eth1 -w /var/tmp/osmo-gsm-tester/trials/trial-100/run.2017-05-17_12-42-22/osmo-nitb_10.42.42.1/pcap/pcap-recorder_eth1.pcap host 10.42.42.1 and port not 22
root     28975 28959  0 12:42 ?        00:00:00 /var/tmp/osmo-gsm-tester/trials/trial-100/inst/osmo-nitb/bin/osmo-nitb -c /var/tmp/osmo-gsm-tester/trials/trial-100/run.2017-05-17_12-42-22/osmo-nitb_10.42.42.1/osmo-nitb.cfg
root     29051 28959  0 12:42 ?        00:00:00 ssh root@10.42.42.114 cd "/osmo-gsm-tester/osmo-bts-sysmo"; LD_LIBRARY_PATH=/osmo-gsm-tester/osmo-bts-sysmo/lib /osmo-gsm-tester/osmo-bts-sysmo/bin/osmo-bts-sysmo -c /osmo-gsm-tester/osmo-bts-sysmo.cfg -r 1 -i 10.42.42.1

#5 Updated by pespin about 1 month ago

Here's a better example. I see osmo-gsm-tester + subprocesses. I kill osmo-gsm-tester. Subprocesses are still alive afterwards:

root@osmo-gsm-tester-rnd:~# ps -ef | grep osmo
root     29466 29464 28 12:50 ?        00:00:22 python3 -u ./osmo-gsm-tester.py /var/tmp/osmo-gsm-tester/trials//trial-100 -s sms
root     29480 29466  0 12:50 ?        00:00:00 tcpdump -n -i eth1 -w /var/tmp/osmo-gsm-tester/trials/trial-100/run.2017-05-17_12-50-48/osmo-nitb_10.42.42.1/pcap/pcap-recorder_eth1.pcap host 10.42.42.1 and port not 22
root     29481 29466  0 12:50 ?        00:00:00 /var/tmp/osmo-gsm-tester/trials/trial-100/inst/osmo-nitb/bin/osmo-nitb -c /var/tmp/osmo-gsm-tester/trials/trial-100/run.2017-05-17_12-50-48/osmo-nitb_10.42.42.1/osmo-nitb.cfg
root     29490 29466  0 12:51 ?        00:00:00 ssh root@10.42.42.114 cd "/osmo-gsm-tester/osmo-bts-sysmo"; LD_LIBRARY_PATH=/osmo-gsm-tester/osmo-bts-sysmo/lib /osmo-gsm-tester/osmo-bts-sysmo/bin/osmo-bts-sysmo -c /osmo-gsm-tester/osmo-bts-sysmo.cfg -r 1 -i 10.42.42.1
root     29531 20325  0 12:52 pts/0    00:00:00 grep osmo

root@osmo-gsm-tester-rnd:~# kill 29466

root@osmo-gsm-tester-rnd:~# ps -ef | grep osmo
root     29480     1  0 12:50 ?        00:00:00 tcpdump -n -i eth1 -w /var/tmp/osmo-gsm-tester/trials/trial-100/run.2017-05-17_12-50-48/osmo-nitb_10.42.42.1/pcap/pcap-recorder_eth1.pcap host 10.42.42.1 and port not 22
root     29481     1  0 12:50 ?        00:00:00 /var/tmp/osmo-gsm-tester/trials/trial-100/inst/osmo-nitb/bin/osmo-nitb -c /var/tmp/osmo-gsm-tester/trials/trial-100/run.2017-05-17_12-50-48/osmo-nitb_10.42.42.1/osmo-nitb.cfg
root     29490     1  0 12:51 ?        00:00:00 ssh root@10.42.42.114 cd "/osmo-gsm-tester/osmo-bts-sysmo"; LD_LIBRARY_PATH=/osmo-gsm-tester/osmo-bts-sysmo/lib /osmo-gsm-tester/osmo-bts-sysmo/bin/osmo-bts-sysmo -c /osmo-gsm-tester/osmo-bts-sysmo.cfg -r 1 -i 10.42.42.1

#6 Updated by pespin about 1 month ago

  • Assignee changed from pespin to neels

Patch available here for review: https://gerrit.osmocom.org/#/c/2670/2

#7 Updated by neels about 1 month ago

  • Status changed from Feedback to In Progress
  • Assignee changed from neels to pespin

though I will / did do the patch review, getting a patch through review is still your task and technically could be done by anyone. So IMHO this should remain assigned to and be resolved by you.

#8 Updated by pespin 27 days ago

  • Status changed from In Progress to Resolved
  • % Done changed from 0 to 100

Also available in: Atom PDF