[arch-projects] [netcfg] [PATCH 3/3] systemd: add alternative units with proper dependencies
thomas at archlinux.org
Wed Oct 24 19:14:54 EDT 2012
Am 25.10.2012 01:02, schrieb Tom Gundersen:
> On Thu, Oct 25, 2012 at 12:27 AM, Thomas Bächler <thomas at 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...
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
>> 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 at .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 at .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 netcfg at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 897 bytes
Desc: OpenPGP digital signature
More information about the arch-projects