25

Goal

I'd like to write C/C++ applications and provide an API for them to communicate directly with systemd-managed services. Effectively, I'd like my applications to be able to do the equivalent of systemctl start service_name@unit_number.service without using system(), popen(), or exec() calls (hard requirement).

Question

Is there a simple C/C++ API for communicating with systemd, assuming systemd version 219 (i.e. CentOS v7.4, also a hard requirement)?

Work So Far

  1. I've scoured online for examples of controlling systemd-managed services in C/C++ and found the odd discussion on the topic, but haven't found any good examples.
  2. I could always reverse-engineer systemctl version 219 from source, but then I potentially run afoul of GPL licensing.
  3. Since I'm stuck with CentOS v7.4, which means I can't get at version 221 or later of systemd, I can't use the newer "SD Bus" API. Nobody would allow manually upgrading libsystemd just for an application-specific benefit, and I'm apparently not the first person to raise this concern.
  4. I'm hesitant to use the low-level C API for DBUS, since the maintainers themselves state "If you use this low-level API directly, you're signing up for some pain.".

Hard Requirements

  • systemd v219.
  • CentOS v7.4
  • C/C++.
  • No system()/popen()/exec() calls to the systemctl CLI utility.
  • Non-propagating license (i.e. LGPLv2 is OK, though BSD/MIT is preferred).

Question (Redux)

Is there a simpler API that I could use on CentOS v7.4 (even if I have to supply the shared library myself) that can be used to communicate with systemd in a simple, reliable manner directly via C/C++ code? If the existing libdbus-1.so API is complicated but still reliable, and I can create a reliable/stable wrapper library around it, I'm open to exploring that option. Also, if it's possible to manually build and deploy the SD-BUS components independent of systemd and use them without having to modify/upgrade the systemd library/daemon already on the system, I could potentially go that route too.

Edits & Comments

  • I would be open to using a mature C++ library, so long as it doesn't require total release of all source.

Thank you.

Community
  • 1
  • 1
Cloud
  • 18,753
  • 15
  • 79
  • 153
  • Have you looked into using a C++ wrapper library? There are a few that exist already that make the dbus library easier to use. – rm5248 Jun 10 '18 at 16:27
  • @rm5248 I would be open to using a mature C++ library, so long as it doesn't require total release of all source. Thanks! – Cloud Jun 10 '18 at 18:56
  • Since the systemd API is exposed as a set of D-Bus interfaces, this question essentially boils down to ‘what C/C++ D-Bus bindings do you recommend?’ — which is covered by [this existing answer](https://stackoverflow.com/questions/27751358/how-to-figure-out-which-d-bus-binding-to-use/44696835#44696835), together with their pros and cons. – Philip Withnall Jun 10 '18 at 22:40

1 Answers1

3

As you already figured out, you should only interact with systemd using a dbus library, there is no other supported way to do so. Even if you lifted the requirement of no execution of binaries, it will remain frowned upon, as the *ctl tools are command line user interfaces not intended or designed to be called from other programs.

Cristian Rodríguez
  • 232
  • 1
  • 5
  • You also figured out that this seems to be a common problem and the new "SD Bus" API solves it. Why do you think there is a non-painfull old API when they made a shiny new API to be less painful? – Goswin von Brederlow Jun 21 '18 at 13:31
  • There is indeed adviced to use sd-bus.. but from C++ pretty much the only mature well tested, well supported choice he has is qtdbus. – Cristian Rodríguez Jun 21 '18 at 13:38