On Fri, Oct 10, 2014 at 11:40 PM, Dale R. Worley <wor...@alum.mit.edu> wrote: >> From: Tom Gundersen <t...@jklm.no> > >> What we do, however, is to expose the configuration state using the >> sd-network C API, which external programs can watch and react on (see >> how timesyncd and resolved currently works). > > In a situation where one wants to do what a "hook" does, having a > separate daemon program that watches for an event and then invokes the > hook when the event happens is not a good solution -- it replaces the > hook with an entire daemon. > > I am not experienced, but from what little I know about systemd, the > "natural" way would seem to be to write a new unit file with the > appropriate dependencies. The event that should call the hook is when > some unit finishes starting, and then the new unit would then be > started.
Well, in some cases you can do this. For instance, we have the network-online.target which gets triggered for some notion of "online". However, if you want more fine-grained control than any of the existing units give you, you probably have to hook into rtnl/networkd/udev events to get precisely what you want. For any non-trivial setup, this is likely what you want anyway as you probably need to react to the network coming and going (and not only when it first gets configured). For a few examples of how this hook-up can be done, see networkd-wait-online, timesyncd and resolved in the systemd repo. Cheers, Tom _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
