Bug #2689
closedosmo-pcu exits if BTS not yet available after connecting successfully to the unix socket
0%
Description
If the unix socket is not yet available, osmo-pcu delays the operation and tries again later without dying:
20171128192520877 DL1IF <0001> /home/pespin/dev/sysmocom/git/osmo-pcu/src/osmobts_sock.cpp:229 Opening OsmoPCU L1 inter face to OsmoBTS 20171128192520878 DL1IF <0001> /home/pespin/dev/sysmocom/git/osmo-pcu/src/osmobts_sock.cpp:266 Failed to connect to the osmo-bts PCU socket, delaying... '/tmp/pcu_bts' 20171128192525883 DL1IF <0001> /home/pespin/dev/sysmocom/git/osmo-pcu/src/osmobts_sock.cpp:229 Opening OsmoPCU L1 inter face to OsmoBTS 20171128192525883 DL1IF <0001> /home/pespin/dev/sysmocom/git/osmo-pcu/src/osmobts_sock.cpp:266 Failed to connect to the osmo-bts PCU socket, delaying... '/tmp/pcu_bts'
However, once it successfully connects, it tries to get information from BTS. If BTS says it is not avaialable, osmo.pcu exits the process instead of waiting for new instructions or change of status from BTS, or try re-connecting to the unix socket and trying again with a delay:
20171128192519079 DL1IF <0001> /home/pespin/dev/sysmocom/git/osmo-pcu/src/osmobts_sock.cpp:229 Opening OsmoPCU L1 inter face to OsmoBTS 20171128192519079 DL1IF <0001> /home/pespin/dev/sysmocom/git/osmo-pcu/src/osmobts_sock.cpp:288 osmo-bts PCU socket /tmp /pcu_bts has been connected 20171128192519079 DL1IF <0001> /home/pespin/dev/sysmocom/git/osmo-pcu/src/osmobts_sock.cpp:292 Sending version 0.4.0.7- a5eb to BTS. 20171128192519079 DL1IF <0001> /home/pespin/dev/sysmocom/git/osmo-pcu/src/pcu_l1_if.cpp:107 Sending 0.4.0.7-a5eb TXT as PCU_VERSION to BTS 20171128192519079 DL1IF <0001> /home/pespin/dev/sysmocom/git/osmo-pcu/src/pcu_l1_if.cpp:413 Info indication received: 20171128192519079 DL1IF <0001> /home/pespin/dev/sysmocom/git/osmo-pcu/src/pcu_l1_if.cpp:416 BTS not available [Inferior 1 (process 16689) exited normally]
Updated by laforge over 6 years ago
And once the PCU exits, the BTS also restarts? Or why exactly is this a bug? If it's just the PCU that respawns, nothing is hurt, right?
Yes, in general we should probably work towards living without relying on respawning of processes. But that's more like a new feature than a bugfix?
Updated by pespin over 6 years ago
Well, it's a feature or a bug fix depending on what you expect the good behaviour to be. For me the good behaviour would be that the process is not restarted unless I tell it to do so or because it crashes (unexpectedly). I don't really care whether we take this as a bug or as a feature, but current behaviour should be improved to have a more reliable system without depending on systemd or other means to restart the process.
Updated by stsp about 6 years ago
- Status changed from New to In Progress
I have a patch which seems to fix this problem:
<0001> osmobts_sock.cpp:245 Opening OsmoPCU L1 interface to OsmoBTS <0001> osmobts_sock.cpp:283 Failed to connect to the osmo-bts PCU socket (Connection refused), delaying... '/tmp/pcu_bts' <0001> osmobts_sock.cpp:245 Opening OsmoPCU L1 interface to OsmoBTS <0001> osmobts_sock.cpp:305 osmo-bts PCU socket /tmp/pcu_bts has been connected <0001> osmobts_sock.cpp:309 Sending version 0.4.0.82-c907b to BTS. <0001> pcu_l1_if.cpp:107 Sending 0.4.0.82-c907b TXT as PCU_VERSION to BTS <0001> pcu_l1_if.cpp:416 BTS not available <0001> pcu_l1_if.cpp:430 BTS available <000b> gprs_ns.c:266 NSVCI=65534 Creating NS-VC <000b> gprs_ns.c:1622 Listening for nsip packets from 127.0.0.1:23000 on 0.0.0.0:23020 <000b> gprs_ns.c:1641 NS UDP socket at 0.0.0.0:23020
Updated by stsp about 6 years ago
- Status changed from In Progress to Resolved
The above patch has been merged. Closing this issue.