My computer booted really slow with a message a start job is running for udev wait for complete device initialization .systemd-analyze blame and found out the problem was that systemd-udev-settle took about 6 seconds and NetworkManager-wait-online 2 seconds.
Searching around I found some related issues:
NixOS:master ← peterhoeg:f/udev-settle
opened 03:34AM - 29 Apr 17 UTC
###### Motivation for this change
```systemd-udev-settle.service``` is a left… over from a time when it was possible to say "now all the hardware I will ever need has shown up" and really doesn't make sense in the very dynamic world of today. Additionally is slows down boot by about 1.2 seconds on the hardware I have available.
Yet it is pulled in by the following units:
``` shell
$ ag udev-settle | grep -i -e req -e want
nixos/modules/services/hardware/brltty.nix:42: wants = [ "systemd-udev-settle.service" ];
nixos/modules/services/scheduling/atd.nix:73: wants = [ "systemd-udev-settle.service" ];
nixos/modules/services/x11/xserver.nix:528: wants = [ "systemd-udev-settle.service" ];
nixos/modules/tasks/filesystems/zfs.nix:338: requires = [ "systemd-udev-settle.service" ];
```
I don't have any experience with braille displays or ZFS to say if it is truly needed here so I have left these out, but for ```atd``` and ```display-manager``` it's pointless.
It's tested here on 2 physical machines (a regular desktop and a laptop with a dm-crypt encrypted home) and apart from the improvement in boot speed there is no difference.
All units with default dependencies (ie without ```DefaultDependencies=no```) get an implicit ```After=basic.target``` which implies ```After=local-fs.target``` so that's why I ripped that out of
```display-manager.service``` while at it.
###### Things done
- [x] Tested using sandboxing
([nix.useSandbox](http://nixos.org/nixos/manual/options.html#opt-nix.useSandbox) on NixOS,
or option `build-use-sandbox` in [`nix.conf`](http://nixos.org/nix/manual/#sec-conf-file)
on non-NixOS)
- Built on platform(s)
- [x] NixOS
- [ ] macOS
- [ ] Linux
- [ ] Tested compilation of all pkgs that depend on this change using `nix-shell -p nox --run "nox-review wip"`
- [ ] Tested execution of all binary files (usually in `./result/bin/`)
- [ ] Fits [CONTRIBUTING.md](https://github.com/NixOS/nixpkgs/blob/master/.github/CONTRIBUTING.md).
---
opened 06:02PM - 25 Feb 18 UTC
0.kind: bug
6.topic: nixos
## Issue description
This isn't fully debugged, but I'll share what I know so… far:
Services which depend on reaching the internet, e.g. ZNC, should be marked as depending in systemd's network-online.target, to prevent them from coming up too early.
When there are multiple network addresses expected, it *appears* that the target is reached once even a *single* of them is brought up. For the particular case that bit me, this was a statically configured v6 address combined with a DHCP'd v4 address, with ZNC as a user unit. ZNC started the moment the v6 address was configured, multiple seconds before IPv4 access was available.
In the particular case of ZNC, once it has started, it'll never look for any network interfaces that come up later -- so if the IPv4 interface is down, it'll never be able to reach any v4-only IRC networks unless manually restarted.
I don't know what would happen if there are multiple distinct NICs on the system, but network-online should only be reached once *all* interfaces and addresses are fully configured.
### Steps to reproduce
Here's a listing of every possibly relevant configuration element:
```
networking.hostName = "madoka";
networking.hostId = "f7fcf93e";
# networking.defaultGateway = "138.201.133.1";
# Doesn't work due to missing interface specification.
#networking.defaultGateway6 = "fe80::1";
networking.localCommands = ''
${pkgs.nettools}/bin/route -6 add default gw fe80::1 dev enp0s31f6 || true
'';
networking.nameservers = [ "8.8.8.8" "8.8.4.4" ];
networking.interfaces.enp0s31f6 = {
ip6 = [{
address = "2a01:4f8:172:3065::2";
prefixLength = 64;
}];
};
networking.firewall = {
allowPing = true;
allowedTCPPorts = [
80 443 # Web-server
25565 25566 25567 # Minecraft
4000 # ZNC
12345 # JMC's ZNC
];
allowedUDPPorts = [
34197 # Factorio
];
};
networking.nat = {
enable = true; # For mediawiki.
externalIP = "138.201.133.39";
externalInterface = "enp0s31f6";
internalInterfaces = [ "ve-eln-wiki" ];
};
```
## Technical details
Please run `nix-shell -p nix-info --run "nix-info -m"` and paste the
results.
```
- system: `"x86_64-linux"`
- host os: `Linux 4.9.81, NixOS, 18.03pre-git (Impala)`
- multi-user?: `yes`
- sandbox: `relaxed`
- version: `nix-env (Nix) 1.11.16`
- channels(root): `"nixos-18.03pre125750.a6dca042722"`
- nixpkgs: `/etc/nix-system-pkgs`
```
## Amusing aside
This originally manifested as the IRCCloud Android client repeatedly reconnecting to their servers. It turned out there was a bug in IRCCloud's error parsing for ZNC, causing their server to repeatedly crash whenever ZNC sent an error about being unable to reach systemnet, which of course led to never seeing that error.
So in addition to *this* bug, there were two others -- IRCCloud's, and ZNC's -- combining forces to throw me out of IRC. Debugging this was fun.
However, they don’t offer a solution that works for me. After some trying, I came up with this config:
systemd.services.systemd-udev-settle.enable = false;
systemd.services.NetworkManager-wait-online.enable = false;
and now my nixos system boots amazing fast!
Hope this will help someone else!
3 Likes
The first PR addresses an different issue - telling some units not to pull in systemd-udev-settle so if it’s still firing for you, it’s because something else is pulling it in and ideally we find out what that is and remove it.
Being explicit about disabling it is obviously fine too.
1 Like
Most likely “networking.dhcpcd.enable” is the thing that pulls in systemd-udev-settle. Any idea if it’s safe to remove that one?
rnhmjoj
December 22, 2020, 10:06am
4
I think so, it was added to fix a race condition with the interface renaming but it’s now solved.
https://github.com/NixOS/nixpkgs/pull/107382
2 Likes