[arch-projects] [netcfg] [PATCH 3/3] systemd: add alternative units with proper dependencies

[Thomas Bächler]

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
>>    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 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.

It is.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.archlinux.org/pipermail/arch-projects/attachments/20121025/bee84c61/attachment.asc>