Am 25.10.2012 01:02, schrieb Tom Gundersen:
On Thu, Oct 25, 2012 at 12:27 AM, Thomas Bächler firstname.lastname@example.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...
netcfg is simply a set of bash scripts. I actually don't want to reimplement something in bash that systemd can already do (including some timeout logic, proper display in systemctl status, ...)
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?
This might actually be a good idea - we remove netcfg.service when we merge this, and everything will just keep working without reconfiguration, just ... better.
However, this may cause problems with legacy configurations where people used rc.d/net-profiles before and then switched to netcfg@.service. The networks will still be listed in NETWORKS=(), but netcfg.service is not enabled, so this was ignored. Using this in combination with netcfg@.service will enable the profiles twice.
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 email@example.com, 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.