用于控制systemd服务的简单非CLI(即C/C++)API

Question

目标

我想编写C/C++应用程序并为它们提供一个API,以便直接与systemd托管服务进行通信.实际上,我想我的应用程序能够做的相当的systemctl start service_name@unit_number.service不使用system(),popen()或exec()电话(硬性要求).

---

题

是否有一个简单的 C/C++ API用于通信systemd,假设systemd版本为219(即CentOS v7.4,也是一项硬性要求)？

---

工作到目前为止

1. 我在网上搜索systemd了C/C++ 中控制托管服务的例子,发现了关于这个主题的奇怪讨论,但没有找到任何好的例子.
2. 我总是可以systemctl从源代码中对219版进行逆向工程,但后来我可能会违反GPL许可.
3. 由于我坚持使用CentOS v7.4,这意味着我无法获得版本221或更高版本的systemd,我无法使用更新的"SD Bus"API. 没有人会libsystemd仅仅为了特定应用程序的好处而允许手动升级,而且我显然不是第一个提出这种担忧的人.
4. 我对使用DBUS的低级C API犹豫不决,因为维护者自己说" 如果你直接使用这个低级API,那么你就注册了一些痛苦. "

---

硬要求

• systemd v219.
• CentOS v7.4
• C/C++.
• 否system()/ popen()/ exec()调用systemctlCLI实用程序.
• 非传播许可证(即LGPLv2没问题,但首选BSD/MIT).

---

问题(Redux)

是否有一个更简单的API,我可以在CentOS v7.4上使用(即使我必须自己提供共享库),可以systemd直接通过C/C++代码以简单,可靠的方式与之通信？如果现有的libdbus-1.soAPI很复杂但仍然可靠,并且我可以围绕它创建一个可靠/稳定的包装器库,我很乐意探索这个选项.此外,如果可以独立于手动构建和部署SD-BUS组件systemd并使用它们而无需修改/升级systemd系统上已有的库/守护程序,我也可能会采用这种方式.

---

编辑和评论

• 我愿意使用成熟的C++库,只要它不需要完全释放所有源代码.

谢谢.

Answer 1

正如您已经想到的，您应该只使用 dbus 库与 systemd 交互，没有其他受支持的方法可以做到这一点。即使您取消了不执行二进制文件的要求，它仍然会让人皱眉，因为 *ctl 工具是命令行用户界面，不打算或设计为从其他程序调用。