You are not logged in.
-----Solved----
Turns out it was IWD that was causing the misbehavior not systemd. With a very helpful post from progandy in the IWD thread, I was able to avoid by creating an override file as follows (the key is the --nointerfaces flag in the ExecStart):
cat /etc/systemd/system/iwd.service.d/override.conf
[Unit]
Before=network.target
Wants=network.target
[Service]
ExecStart=
ExecStart=/usr/lib/iwd/iwd --nointerfaces "wlan[0-9]"
-----Solved----
I noticed recently that my udev rules for predictable naming of my wifi card were not going through and confirmed that by grepping the logs. Here's a full journal just in case that's helpful.
$journalctl -b -p err | grep -iv acpi
-- Logs begin at Tue 2018-07-10 22:19:32 EDT, end at Thu 2018-11-08 19:51:01 EST. --
Nov 08 19:29:13 5510 systemd-udevd[557]: Error changing net interface name 'wlan0' to 'wlp1s0': Device or resource busy
$systemctl status systemd-udevd
● systemd-udevd.service - udev Kernel Device Manager
Loaded: loaded (/usr/lib/systemd/system/systemd-udevd.service; static; vendor preset: disabled)
Active: active (running) since Thu 2018-11-08 22:26:49 EST; 19h ago
Docs: man:systemd-udevd.service(8)
man:udev(7)
Main PID: 346 (systemd-udevd)
Status: "Processing with 16 children at max"
Tasks: 1
Memory: 26.8M
CGroup: /system.slice/systemd-udevd.service
└─346 /usr/lib/systemd/systemd-udevd
Nov 08 22:26:49 5510 systemd[1]: Starting udev Kernel Device Manager...
Nov 08 22:26:49 5510 systemd[1]: Started udev Kernel Device Manager.
Nov 08 22:26:50 5510 systemd-udevd[388]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Nov 08 22:26:50 5510 systemd-udevd[554]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Nov 08 22:26:50 5510 systemd-udevd[554]: Error changing net interface name 'wlan0' to 'wlp1s0': Device or resource busy
Nov 08 22:26:50 5510 systemd-udevd[554]: could not rename interface '2' from 'wlan0' to 'wlp1s0': Device or resource busy
Confirmed that this seems to have happened since the last upgrade of systemd from 239.2-1 -> 239.300-1
$grep -a upgraded /var/log/pacman.log | grep -i systemd | tail -n 10
[2018-07-05 19:14] [ALPM] upgraded systemd (238.133-4 -> 239.0-2)
[2018-07-05 19:15] [ALPM] upgraded systemd-sysvcompat (238.133-4 -> 239.0-2)
[2018-09-14 17:34] [ALPM] upgraded libsystemd (239.0-2 -> 239.2-1)
[2018-09-14 17:34] [ALPM] upgraded systemd (239.0-2 -> 239.2-1)
[2018-09-14 17:34] [ALPM] upgraded systemd-sysvcompat (239.0-2 -> 239.2-1)
[2018-09-25 18:12] [ALPM] upgraded lib32-systemd (239.0-1 -> 239.2-1)
[2018-11-06 18:30] [ALPM] upgraded libsystemd (239.2-1 -> 239.300-1)
[2018-11-06 18:30] [ALPM] upgraded systemd (239.2-1 -> 239.300-1)
[2018-11-06 18:30] [ALPM] upgraded lib32-systemd (239.2-1 -> 239.300-1)
[2018-11-06 18:30] [ALPM] upgraded systemd-sysvcompat (239.2-1 -> 239.300-1)
Happens on both latest default Arch kernel and ZEN, running default right now though.
$uname -a
Linux 5510 4.18.16-arch1-1-ARCH #1 SMP PREEMPT Sat Oct 20 22:06:45 UTC 2018 x86_64 GNU/Linux
At first I thought it was an issue with the custom udev rules I had set up, so to take them out the equation I removed the rules.
$ls -al /etc/udev/rules.d/
total 16
drwxr-xr-x 2 root root 4096 Nov 7 19:06 .
drwxr-xr-x 4 root root 4096 Nov 8 19:29 ..
-rw-r--r-- 1 root root 553 May 29 18:27 60-scheduler.rules
-rw-r--r-- 1 root root 113 May 29 18:29 hd_power_save.rules
And I'm still getting the same error in the logs. I even tried using a .link file instead, with the same result. I am using systemd-boot and here's relevant mkinitcpio.conf if helpful.
$grep -v "^\#" /etc/mkinitcpio.conf
MODULES=(intel_agp i915)
BINARIES=()
FILES=(/etc/modprobe.d/modprobe.conf /etc/modprobe.d/iwlwifi.conf /etc/modprobe.d/i915.conf /etc/modprobe.d/audio_powersave.conf /etc/modprobe.d/itco_wdt.conf /etc/modprobe.d/scsi.conf /etc/modprobe.d/dm.conf /etc/sysctl.d/40-max-user-watches.conf)
HOOKS=(base systemd autodetect keyboard sd-vconsole modconf block sd-encrypt sd-lvm2 filesystems fsck)
Nothing crazy with services, I don't think anyway.
$systemctl list-unit-files --state=enabled
UNIT FILE STATE
autovt@.service enabled
dbus-org.freedesktop.network1.service enabled
dbus-org.freedesktop.resolve1.service enabled
display-manager.service enabled
getty@.service enabled
iwd.service enabled
libvirtd.service enabled
lm_sensors.service enabled
pdnsd.service enabled
sddm.service enabled
systemd-networkd.service enabled
systemd-resolved.service enabled
systemd-timesyncd.service enabled
sshd.socket enabled
systemd-networkd.socket enabled
virtlockd.socket enabled
virtlogd.socket enabled
remote-fs.target enabled
fstrim.timer enabled
Not sure where to look next, any thoughts?
Last edited by CarbonChauvinist (2018-11-10 13:06:55)
"the wind-blown way, wanna win? don't play"
Offline
I encountered this problem, too, and based on the suggestions in systemd#7293 was able to fix it using a slightly different override file:
$ cat /etc/systemd/system/iwd.service.d/01-after-udev.conf
[Service]
ExecStartPre=/usr/bin/udevadm settle -E /sys/class/net/wlp4s0
Offline
Interesting; your approach when starting the iwd service is to first run udevadm settle, the -E flag may be useful here:
-E --exit-if-exists=FILE Stop waiting if file exists
I think the original override from your link was for the networkd service, not iwd? If you notice he overrides networkd. I guess changing the target from networkd to iwd should have the same effect. Also, there were reports that overriding networkd didn't work for everyone in the thread anyway.
This thread's post, though for another OS, seems to get to the crux of the issue:
After some tests, here's what I think is happening: Stage 1 udev discovers and adds the network interfaces with their original ethX names. Renaming doesn't happen until stage 2. But networkd tries to configure all interfaces it finds, so there's a race condition between stage 2 udev and networkd.
Based on this forum post I've actually since changed my override to the following:
$ cat /etc/systemd/system/iwd.service.d/override.conf
[Unit]
BindsTo=sys-subsystem-net-devices-wifi0.device
After=sys-subsystem-net-devices-wifi0.device
[Service]
ExecStart=
ExecStart=/usr/lib/iwd/iwd --interface wifi0
Have had good results:
journalctl -b -p err | grep -iv acpi
-- Logs begin at Tue 2018-08-14 21:09:30 EDT, end at Sat 2018-11-24 23:30:38 EST. --
systemctl status iwd
● iwd.service - Wireless service
Loaded: loaded (/usr/lib/systemd/system/iwd.service; enabled; vendor preset: disabled)
Drop-In: /etc/systemd/system/iwd.service.d
└─override.conf
Active: active (running) since Sat 2018-11-24 07:44:33 EST; 15h ago
Main PID: 459 (iwd)
Tasks: 1 (limit: 4915)
Memory: 1.4M
CGroup: /system.slice/iwd.service
└─459 /usr/lib/iwd/iwd --interface wifi0
Nov 24 07:44:32 5510 iwd[459]: Wireless daemon version 0.6
Nov 24 07:44:32 5510 iwd[459]: Skipping optional configuration file //etc/iwd/main.conf
Nov 24 07:44:32 5510 iwd[459]: rfkill id 0 can't be matched to a wiphy
Nov 24 07:44:32 5510 iwd[459]: Wiphy: 0, Name: phy0
Nov 24 07:44:32 5510 iwd[459]: Bands: 2.4 GHz 5 GHz
Nov 24 07:44:32 5510 iwd[459]: Ciphers: CCMP TKIP BIP
Nov 24 07:44:32 5510 iwd[459]: Supported iftypes: ad-hoc station ap
Nov 24 07:44:33 5510 systemd[1]: Started Wireless service.
I'm not sure which approach is best and am interested in others' thoughts.
Last edited by CarbonChauvinist (2018-11-25 05:05:40)
"the wind-blown way, wanna win? don't play"
Offline