On Thu, Oct 25, 2012 at 12:27 AM, Thomas Bächler <thomas@archlinux.org> wrote:
Until now, netcfg might fail to start because it is started too early (this actually happened to me quite regularly). To fix this, we need to make systemd aware of the dependencies of a profile.
(Note: I know nothing about netcfg) Is there no way to teach netcfg to just wait for the devices to become available, so that there is no "too early"? This is how other network management daemons work...
This commit adds a systemd generator that creates profiles with the names netcfg-profile-$PROFILE.service on boot. The ugly part: You cannot permanently enable such a profile, as it is generated during boot. To enable it, put it in NETWORKS=() in /etc/conf.d/netcfg and run systemctl enable netcfg-profiles.target
Hmm... Not a big fan of having two levels of "on/off". Any reason not to do this like the other standard generators (for fstab and crypttab)? I.e., to make netcfg-profiles.target statically enabled, so that NETWORK=() is the one and only place to enable profiles?
If you add a new profile, you need to reload the systemd configuration so the service file shows up.
While this scheme is less intuitive than netcfg@profilename.service, it is the only way to provide proper dependencies during boot.
Makes sense to me, just make clear it is similar to how fstab/crypttab works, and there should be no room for confusion. -t