Feature #2227
closedosmo-gsm-tester: launch processes using systemd
0%
Description
So far osmo-gsm-tester launches subrocesses directly using python's subprocess.Popen. This could instead be a configured systemd tree, where we obtain status information and events using dbus.
A particular detail is the sysmoBTS: we also so far scp libraries and binaries to a separate dir and run the osmo-bts-sysmo as a python subprocess via ssh. Instead we may want to install the binaries and libraries in /usr and use the sysmobts.service to run/stop the sysmoBTS. (This would also take care of DSP reloading instead of doing that via ssh.) An improvement there would be that we're actually running the identical setup as with a user installation, instead of running a special case using a different LD_LIBRARY_PATH.
With systemd we would need configurations to not restart automatically etc., to have the same semantics as the current subprocess.Popen() implementation: if a process ended, that should propagate as a failure into the test run.
Updated by pespin over 6 years ago
- Status changed from New to Feedback
- Assignee changed from 55360 to neels
I don't think this is really needed.
For sure it's not a good idea for processes running in the main unit, since that would limit to 1 process/service per system (or user if using systemd user services), which means we could for instance not have 2 osmo-bts-trx running in one test, or we could not have 2 osmo-msc running if more than 1 test or osmo-gsm-tester instance is running in parallel.
For sysmobts case, I don't see big benefits and on the other hand we would need to find a new way to take the process stdout and stderr from somewhere if we move to use systemd, while we already have that easily by using Popen and ssh.
neels, what do you think, can we close this task as invalid?
