On Fri, 10.10.14 17:40, 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. The new unit's ExecStart command would be the desired > invocation of the hook. > > Does that make sense? If it does, it might be useful to write a > beginner's guide on how to construct and insert such a unit into a > system.
Any synchronous hooks (regardless if implemented via direct callouts or via systemd units) are something I really want to avoid here. Networking is generally asynchronous, so pretending we could do things synchronously here sounds making a promise we can't keep, after all other apps usually watch connectivity directly via rtnl and such. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
