On 10/14/2011 09:05 AM, Jaroslav Reznik wrote:
----- Original Message -----
Greetings,
I came across an issue with how the services agent works that makes it seriously impaired in Fedora 16 and above (systems that make heavy use of systemd).
The services agent supports two different "standards" on Linux: OCF and LSB. In the OCF case, it's executing OCF resource agents. That's all fine. In the LSB case, it's running scripts in /etc/init.d. Also keep in mind that there are two APIs in the services agent: Services and Resources. The Resources API is the more advanced version. The Services API is much simpler, and uses the code for the LSB standard under the hood.
For example, if you run this QMF API call:
Services::start("httpd")
that turns into running this command on the host:
# /etc/init.d/httpd start
Some work is needed here. Here is a first pass at what I think needs to be done.
- Add a "systemd" standard to the Resources API.
I don't think we need to venture into adding any new API calls here. We should just make the existing API work.
Yep, it's just making new systemd standard work, some refactoring in services agents/library is needed - now standards are for example listed directly from dbus/qmf agent code, should be in library, also read the next comment...
- Change the Services agent to use the systemd API if possible, and
fall back to the LSB if systemd is not in use.
...as I'm not sure fallback to LSB is what we need in Services. The reason is - systemd services do not map directly to LSB services. This means - you have to know which init system you're talking to. For example sshd service in systemd is divided to several services (as I talked to people familiar with systemd, there's possibility to get "group" support and Petr Lautrbach thinks it's a good use- case), so running "service_a" on LSB is not enough on systemd. As Service part of agent should be the simple one, I'd prefer to use default init system only. And expose only available! init systems in Resources API, so if someone really wants to talk to LSB and LSB is available, he can.
These are my initial thoughts, so please comment too :)
Also the way how the library is written, we have to go with direct calling systemctl, instead of dbus way, at least short term.
All of your comments make sense to me. I'm also good with going the systemctl route if that does everything needed. I understand that using D-bus would be much more invasive to the services library.