Systemctl library needs a way to tell unit's status

[CRImier]

Knowing whether a service is running would be useful for quickly writing a wrapper app for a service (such as shairport) We have a library that already works with systemctl (apps/system_apps/systemctl/systemctl.py), but it doesn't yet have a way to tell whether a service is currently running, and this would be useful both for the Systemctl app, as a base for other apps (that could expose start/stop/status + some other functions in a user-friendly manner), and as a way for apps to check whether services they depend on are running.

Related: #46

[CRImier]

We've been brought significantly closer to this with #84, thanks to @bjoernfan - now, we just need to use appropriate DBus parameters and provide our own interface =)

[CRImier]

Small chat on IRC about this feature, with a clarification:

<CRImier> https://github.com/ZeroPhone/ZPUI/issues/82
<CRImier> s/processes'/service's/
<CRImier> basically, I want to make it easier for apps to control services
<CRImier> but then, we need to be able to get their status in a more easy way
<CRImier> for example:
<CRImier> systemctl status getty@tty1.service
<CRImier> you get info like "loaded", "enabled", "active" and "running"
<CRImier> that's pretty much the least I could expect from getting a unit's
status using that library
[...]
<bjoernfan> CRImier: If the purpose of checking service status is for apps to
make sure that services they depend on are running I don't think we need that,
instead "service apps" we create should have their own systemd unit file and
just list the services our service depends on and systemd will take care of
making sure that the required services are running.
<bjoernfan> https://www.freedesktop.org/software/systemd/man/systemd.unit.html
<bjoernfan>
https://www.freedesktop.org/software/systemd/man/systemd.unit.html#%5BUnit%5D%20Section%20Options
- Requires=
<bjoernfan> If that's what we need I can put that in a comment to issue #82
<CRImier> bjoernfan: that's not the usecase (launching the service when the
app is running), and even if it were, that's not doable right now either
<CRImier> The usecase is having some service (i.e. shairport-sync) that
doesn't need to run all the time, and having an app that allows you to launch
that service
<CRImier> start or stop it at will, tell you its status and so on
<CRImier> okay, correction
<CRImier> " that's not doable right now either" => "the way you're proposing
is not doable right now either"
<CRImier> there are times when apps depend on a service, sure, and then the
mechanism you're proposing could make sense
<CRImier> but that's not the main usecase, the main usecase will actually
interfere with "make apps depend on their services" mechanism
<CRImier> because the usecase's for services that don't need to run all the
time - for reasons like battery consumption, security, or whatever else, maybe
they just don't *need* to
<CRImier> and the thing is - apps are loaded as ZPUI plugins right now 
<CRImier> within confines of a single process and a single systemd service
<CRImier> so, such dependencies would be tricky to implement, too
<CRImier> (only at this moment in ZPUI development, the app separation is
indeed one of our targets)