On Tue, Dec 2, 2014 at 10:24 AM, Łukasz Stelmach <l.stelm...@samsung.com> wrote: > It was <2014-12-02 wto 00:35>, when Lennart Poettering wrote: >> On Mon, 24.11.14 09:30, Łukasz Stelmach (l.stelm...@samsung.com) wrote: >> >>> It was <2014-11-21 pią 21:36>, when Lennart Poettering wrote: >>> > On Fri, 21.11.14 17:07, Łukasz Stelmach (l.stelm...@samsung.com) wrote: >>> > >>> >> On a system configured without networkd and sysusers there still needs >>> >> to be the unnecessary systemd-network user, otherwise systemd-tmpfiles >>> >> fails to start. >>> >> >>> >> Move information associated with networkd in tmpfiles.d and sysusers.d >>> >> to separate files. Do not install it if netwrorkd is not enabled. >>> > >>> > In principle looks OK, but I'd prefer if we would write this out with >>> > m4 (see etc.conf.m4) and keep it in the current files, rather than >>> > split this up in numerous files. >>> > >>> > Especially in the case of /run/systemd/netif this actually matters: if >>> > we split that out into its own tmpfiles snippet, then packagers would >>> > most likely put that in its own RPM/DEB if they split out those >>> > daemons. But this is not advisable in this case, as sd-network (which >>> > will eventually be a public API of libsystems) needs the directory to >>> > be around to install an inotify watch. If the directory doesn't exist, >>> > and the API is used it will fail entirely, which is suboptimal, given >>> > that networkd might be installed later on, and things should then just >>> > start to work. >>> >>> Will it be necessary for this directory to be owned by systemd-network >>> even without networkd? >> >> Yes. If networkd is compile-time enable the dir should exist and be >> properly owned, even if it networkd is split off into a separate >> binary package and currently not installed. > > And what if the networkd is disabled? Does the directory must exist? Now > if networkd is disabled /run/systemd/netif* are not in > tmpfiles.d/systemd.conf. Is this correct?
No, if you disable networkd at compile-time the directory is not needed (and using the sd-network library will rightly fail). The reason we need to be able to use the sd-network library in case networkd is enabled, but not installed is that you should be able to start listening, _then_ install networkd, and then be notified of events as if networkd was always installed. However, that only really makes sense if you do enable networkd at comiple-time, but ship it as a separate package. If you disable networkd at compile-time, and then want to introduce it in the distro (as separate package or as part of systemd), I don't think it is unreasonable to expect to have to restart daemons that can optionally integrate with networkd before they start picking up network events. My two cents. -t _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel