Re: [systemd-devel] dbus API for unit state change?
On Sun, 06.10.13 21:11, Brandon Philips (bran...@ifup.co) wrote: On Sun, Oct 6, 2013 at 3:10 PM, Lennart Poettering lenn...@poettering.net wrote: So, yeah, if you respond to each UnitNew signal you get with a property Get/GetAll call, then this will result in endless ping pong, which is certainly not a good idea. What are you trying to do? Write some tool that tracks all units that are loaded? Yes, I want to register services into a networked service registry. An example use case would be an HTTP load balancer that is service registry aware and adds machines to the load balancer based on certain unit files appearing/leaving. An alternative solution is making a user explicitly add a service-registry-notifier@.service to my-application.service.wants but I wanted to avoid making registration a special case. For example: https://gist.github.com/philips/6710008 Maybe there is a middle ground solution? Does it makes sense to send LoadState with UnitNew? I will have to look tomorrow because I think without that trying to do other things gets racy with transient units. Hmm, so I thought a bit about the issue. If I got this right, then you get the UnitNew, immediately issue a Get/GetAll, then you get a UnitRemoved, then you get another UnitNew, and then the response to Get/GetAll, right? If so, it would work to simply ignore all UnitNew signals between the response and the request, no? Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] dbus API for unit state change?
On Fri, 04.10.13 17:19, Brandon Philips (bran...@ifup.co) wrote: Another dbus question: Is it expected that a UnitNew and UnitRemove are sent when I use org.freedesktop.DBus.Properties.Get or GetAll? This also happens with `systemctl status doesnt-exist.service` Yupp it kinda is. The logic behing this is that systemd minimizes the unit file descriptions it has loaded into memory. Basically, unit files are unloaded if they are not active and if no other unit that is loaded references them. Each time something is loaded or unloaded you get a UnitNew or UnitRemoved signal, to keep you updated what is currently in memory. Any unit request will implicitly load the units referenced by it, in order to make this scheme race-free for the client. Here is an example of what I am seeing: https://gist.github.com/philips/6834913/raw/5bd36998829ca44c25c3798afd3c77c147b1ba27/gistfile1.txt This isn't very nice because I need to explicitly guard against getting into an infinite loop of looking up properties on non-existent units. So, yeah, if you respond to each UnitNew signal you get with a property Get/GetAll call, then this will result in endless ping pong, which is certainly not a good idea. What are you trying to do? Write some tool that tracks all units that are loaded? Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] dbus API for unit state change?
On Sun, Oct 6, 2013 at 3:10 PM, Lennart Poettering lenn...@poettering.net wrote: So, yeah, if you respond to each UnitNew signal you get with a property Get/GetAll call, then this will result in endless ping pong, which is certainly not a good idea. What are you trying to do? Write some tool that tracks all units that are loaded? Yes, I want to register services into a networked service registry. An example use case would be an HTTP load balancer that is service registry aware and adds machines to the load balancer based on certain unit files appearing/leaving. An alternative solution is making a user explicitly add a service-registry-notifier@.service to my-application.service.wants but I wanted to avoid making registration a special case. For example: https://gist.github.com/philips/6710008 Maybe there is a middle ground solution? Does it makes sense to send LoadState with UnitNew? I will have to look tomorrow because I think without that trying to do other things gets racy with transient units. Thanks, Brandon ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] dbus API for unit state change?
Another dbus question: Is it expected that a UnitNew and UnitRemove are sent when I use org.freedesktop.DBus.Properties.Get or GetAll? This also happens with `systemctl status doesnt-exist.service` Here is an example of what I am seeing: https://gist.github.com/philips/6834913/raw/5bd36998829ca44c25c3798afd3c77c147b1ba27/gistfile1.txt This isn't very nice because I need to explicitly guard against getting into an infinite loop of looking up properties on non-existent units. Thanks, Brandon On Thu, Oct 3, 2013 at 6:04 AM, Brandon Philips bran...@ifup.co wrote: On Thu, Oct 3, 2013 at 5:54 AM, Mantas Mikulėnas graw...@gmail.com wrote: They do, but the state might have changed again between receiving PropertiesChanged and retrieving the new value. This is OK for my current use case. I will program against PropertiesChanged and wait for Lennart's changes that include the changed property. Thanks, Brandon ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] dbus API for unit state change?
On Thu, 03.10.13 06:05, Mantas Mikulėnas (graw...@gmail.com) wrote: On Thu, Oct 3, 2013 at 5:27 AM, Brandon Philips bran...@ifup.co wrote: Hello- While writing against the dbus bindings I found one missing feature: signals from org.freedesktop.systemd1.Manager on unit ActiveState changes. I can do this today by polling ListUnits but I would rather not have my process doing this. There are two possible APIs: 1. Distinct signal per type UnitActive() UnitInactive() UnitReloading() UnitFailed() UnitActivating() UnitDeactivating() 2. One signal type for all changes: UnitActiveStateChanged() This would encode the ActiveState and SubState in that signals properties. That seems a much simpler. Before writing the patch I wanted to get some feedback on the API and make sure this hadn't been implemented for some other reason either. This is already handled by the PropertiesChanged signal in the standard org.freedesktop.DBus.Properties interface. (Although systemd only sends invalidated_properties and the new values have to be retrieved manually, so that's not really perfect yet.) The latter is going to change soonishly btw. I am currently working on adding automatic property handling support to libsystemd-bus. With that in place we'll like start sending the actual property contents around too, and not just invalidate things. Client libraries hence need to handle PropertiesChanged signals in full, i.e. handle both invalidating messages and the others for the same properties even if for now only invalidating messages are sent. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] dbus API for unit state change?
On Thu, Oct 3, 2013 at 3:06 PM, Lennart Poettering lenn...@poettering.net wrote: On Thu, 03.10.13 06:05, Mantas Mikulėnas (graw...@gmail.com) wrote: This is already handled by the PropertiesChanged signal in the standard org.freedesktop.DBus.Properties interface. (Although systemd only sends invalidated_properties and the new values have to be retrieved manually, so that's not really perfect yet.) The latter is going to change soonishly btw. I am currently working on adding automatic property handling support to libsystemd-bus. With that in place we'll like start sending the actual property contents around too, and not just invalidate things. Client libraries hence need to handle PropertiesChanged signals in full, i.e. handle both invalidating messages and the others for the same properties even if for now only invalidating messages are sent. They do, but the state might have changed again between receiving PropertiesChanged and retrieving the new value. -- Mantas Mikulėnas graw...@gmail.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] dbus API for unit state change?
On Thu, Oct 3, 2013 at 5:54 AM, Mantas Mikulėnas graw...@gmail.com wrote: They do, but the state might have changed again between receiving PropertiesChanged and retrieving the new value. This is OK for my current use case. I will program against PropertiesChanged and wait for Lennart's changes that include the changed property. Thanks, Brandon ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] dbus API for unit state change?
On Thu, Oct 3, 2013 at 5:27 AM, Brandon Philips bran...@ifup.co wrote: Hello- While writing against the dbus bindings I found one missing feature: signals from org.freedesktop.systemd1.Manager on unit ActiveState changes. I can do this today by polling ListUnits but I would rather not have my process doing this. There are two possible APIs: 1. Distinct signal per type UnitActive() UnitInactive() UnitReloading() UnitFailed() UnitActivating() UnitDeactivating() 2. One signal type for all changes: UnitActiveStateChanged() This would encode the ActiveState and SubState in that signals properties. That seems a much simpler. Before writing the patch I wanted to get some feedback on the API and make sure this hadn't been implemented for some other reason either. This is already handled by the PropertiesChanged signal in the standard org.freedesktop.DBus.Properties interface. (Although systemd only sends invalidated_properties and the new values have to be retrieved manually, so that's not really perfect yet.) -- Mantas Mikulėnas graw...@gmail.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
