Instead it's enough to depend on
sys-subsystem-net-devices-<interface>.device, which in turn has a
"wants" dependency on the service (if any) that creates the interface.
For each statically configured interface, we now create a unit
‘<interface>-cfg.service’ which gets started as soon as the network
device comes up. Similarly, each bridge defined in
‘networking.bridges’ and virtual interface in ‘networking.interfaces’
is created by a service ‘<interface>.service’.
So if we have
networking.bridges.br0.interfaces = [ "eth0" "eth1" ];
networking.interfaces =
[ { name = "br0";
ipAddress = "192.168.1.1";
}
];
then there will be a unit ‘br0.service’ that depends on
‘sys-subsystem-net-devices-eth0.device’ and
‘sys-subsystem-net-devices-eth1.device’, and a unit ‘br0-cfg.service’
that depends on ‘sys-subsystem-net-devices-br0.device’.
This is broken because it requires restarting applications to see new
NSS modules. The proper way to handle NSS modules is through nscd.
See commit 554ae9908b.
The upower daemon needs the gdbus command (which is weird given that
upower links against dbus_glib, but ah well...). This fixes suspend
in KDE with systemd.
Alsa-utils provides a udev rule to restore volume settings, so use
that instead of restoring them from a systemd service. The
"alsa-store" service saves the settings on shutdown.
It's not enough to say "after udev-settle.service" since
udev-settle.service is not wanted/required anywhere - we need to say
"wants udev-settle.service" as well.
This should fix problems with ALSA and X11 initialisation that people
have been seeing.
So instead of:
boot.systemd.services."foo".serviceConfig =
''
StartLimitInterval=10
CPUShare=500
'';
you can say:
boot.systemd.services."foo".serviceConfig.StartLimitInterval = 10;
boot.systemd.services."foo".serviceConfig.CPUShare = 500;
This way all unit options are available and users can set/override
options in configuration.nix.
