On Di, 16.01.18 16:13, Tomasz Michalski ([email protected]) wrote: > And I have other question. Generally we wonder what will be better design > for monitoring systemd services > 1.) > - add-match to ActiveState > - subscribe to systemd1.Manager > - then we have to start in separate thread some infinitive-loop with > sd_bus_wait() > and sd_bus_process() (*) > 2.) > - asking for example each 5s all services with the aid of method > sd_bus_get_property about ActiveState. None additional thread is required > in our case as timer when expires send notification to existed infinity > while loop from current handler. > > I wonder which solution occupy more processor. From the first glance it > seems like second one, because there might be too much unnecessary > communication through the bus in order to get to know about systemd service > states. > However take care that here (*) we have to have some infinity while loop > probably in separate thread which will block thread waiting for signals > from systemd. As far as timers are concerned in 2nd solution none > additional thread is required. Is it possible somehow in 1.) not to have > additional thread in order to receive signal from systemd? > Moreover 2nd solution seems to be better in case when systemd1.Manager fail > at all (will be killed). In 2nd solution we will get to know it immediately > as there will be none response on sd_bus_get_property. In 1.) solution we > won't know that, thinking services are in active state. > Thanks in advance for your opinions.
This of course all matters on how much stuff actually happens on your system. I generally would suggest watching the PropertiesChanged stuff with a precise "path" match. But if you have services that change state all the time, then polling might be better. But I'd not go for that option unless oyu have hard performance data. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/systemd-devel
