> 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. Dale _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
