iwd erzeugt SIGSEGV

Dakuan

Durch einen Coredump, der von eines meiner Programme erzeugt wurde, ist mir aufgefallen, dass da noch sehr viel mehr sind, die mir bisher nicht aufgefallen sind.

Angefangen hat das am 22. Nov. 2025 21:50. Ausgelöst wohl durch ein Upgrade zwei Tage vorher. Das pacman.log zeigt:

[2025-11-20T10:38:57+0100] [ALPM] upgraded iwd (3.9-1 -> 3.10-1)
[2026-03-22T21:47:59+0100] [ALPM] upgraded iwd (3.10-1 -> 3.12-1)

Die letzten Zeilen von coredunpctl:

...
Sat 2026-08-15 20:20:11 CEST 340862 1000 984 SIGSEGV present      /home/manfred/prog/gui/dbm/dbman                      >
Sat 2026-08-15 22:45:36 CEST 344590 1000 984 SIGABRT present      /usr/bin/ddd                                 
Sat 2026-08-15 22:45:36 CEST 344601 1000 984 SIGSEGV present      /usr/bin/ddd                                          
Sat 2026-08-15 22:45:37 CEST 341514 1000 984 SIGSEGV present      /usr/bin/ddd                                          
Sun 2026-08-16 09:00:45 CEST 315367    0   0 SIGSEGV inaccessible /usr/lib/iwd/iwd                                     
Sun 2026-08-16 09:13:58 CEST 345460    0   0 SIGSEGV inaccessible /usr/lib/iwd/iwd                                   
Sun 2026-08-16 15:18:17 CEST 346590    0   0 SIGSEGV inaccessible /usr/lib/iwd/iwd                                     
Mon 2026-08-17 10:56:08 CEST 360560    0   0 SIGSEGV inaccessible /usr/lib/iwd/iwd  
Mon 2026-08-17 19:51:50 CEST    521    0   0 SIGSEGV inaccessible /usr/lib/iwd/iwd

Heute um 19:51 hatte ich das System neu gestartet. Das Problem scheint aber auch aufzutreten, wenn der Rechner aus dem Ruhezustand aufgeweckt wird. Danach läuft iwd aber:

[manfred@noir ~]$ pidof iwd
1428
[manfred@noir ~]$

ich käme ja sonst nicht ins Internet.

Das ist mir lange Zeit nicht aufgefallen, da ich meine Fehler verdächtigen Programme meisten mit dem ddd Debugger starte. ddd hat die schöne Eigenschaft, einen Coredump abzufangen und das verursachende Programm im Speicher zu belassen. Durch das 'bt' Menü erhält man dann meistens die Absturzstelle und hat dann auch noch Zugriff auf die Variablen, ein Luxus den ein Core-File nicht bietet.

GerBra

Vielleicht noch dazu schreiben, ob du iwd "standalone" nutzt oder z.B. als Teil des Networkmanagers.
Evtl. interessant wäre auch der komplette Zusammenhang im Journal wenn dieser segfault/coredump passiert.

Dakuan

Wie kann ich das feststellen? Networkmanager habe ich nicht bewusst installiert. Ich hatte damals auch Probleme W-LAN überhaupt zum laufen zu bekommen. Das deutsche WIKI war wohl veraltet und das englische funktionierte auch nicht. Ich fand dann ein U-Tube Video, was auch nicht funktionierte, aber dann eine hilfreiche Fehlermeldung ausgeworfen hatte und ein fehlendes Paket erwähnte, was ich dann installiert hatte. Was das jetzt war, kann ich in meiner altertümlichen Zettelwirtschaft nicht zeitnah feststellen (ich müsste erst meinen Schreibtisch aufräumen).

Ich vermute aber, dass der Networkmanager nicht installiert ist.

[manfred@noir ~]$ which networkmanager
which: no networkmanager in (/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl)
[manfred@noir ~]$ which network-manager
which: no network-manager in (/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl)
[manfred@noir ~]$

Evtl. interessant wäre auch der komplette Zusammenhang im Journal wenn dieser segfault/coredump passiert.
Ich dachte ich hätte das klar gemacht indem ich das System neu gestartet hatte und kurz darauf die Abfrage getätigt hatte.

Moment, ich bin ja auch Admin:

[root@noir manfred]# coredumpctl debug 521
           PID: 521 (iwd)
           TID: 521 (iwd)
           UID: 0 (root)
           GID: 0 (root)
        Signal: 11 (SEGV) si_code: SEGV_MAPERR
     Timestamp: Mon 2026-08-17 19:51:49 CEST (2h 13min ago)
  Command Line: /usr/lib/iwd/iwd
    Executable: /usr/lib/iwd/iwd
 Control Group: /system.slice/iwd.service
          Unit: iwd.service
         Slice: system.slice
       Boot ID: 3ddcb92169e04eff9deff3156557db79
    Machine ID: d58c1752cab249f0a8f17df73e26fe92
      Hostname: noir
       Storage: /var/lib/systemd/coredump/core.iwd.0.3ddcb92169e04eff9deff3156557db79.521.1786989109000000.zst (present)
  Size on Disk: 60.6K
       Message: Process 521 (iwd) of user 0 dumped core.
                
                Stack trace of thread 521:
                #0  0x00005616ad9f14fc n/a (iwd + 0x2a4fc)
                #1  0x00005616ada40c2c n/a (iwd + 0x79c2c)
                #2  0x00007fb576d3e5ef n/a (libell.so.0 + 0x695ef)
                #3  0x00007fb576d3e8a6 l_notifylist_notify_matches (libell.so.0 + 0x698a6)
                #4  0x00007fb576cf787b n/a (libell.so.0 + 0x2287b)
                #5  0x00007fb576ce825f n/a (libell.so.0 + 0x1325f)
                #6  0x00007fb576ced4d5 l_main_iterate (libell.so.0 + 0x184d5)
                #7  0x00007fb576ced93e l_main_run (libell.so.0 + 0x1893e)
                #8  0x00007fb576cef2e6 l_main_run_with_signal (libell.so.0 + 0x1a2e6)
                #9  0x00005616ad9d2e15 n/a (iwd + 0xbe15)
                #10 0x00007fb576a27781 n/a (libc.so.6 + 0x27781)
                #11 0x00007fb576a278b9 __libc_start_main (libc.so.6 + 0x278b9)
                #12 0x00005616ad9d36d5 n/a (iwd + 0xc6d5)
                ELF object binary architecture: AMD x86-64

GNU gdb (GDB) 17.2
Copyright (C) 2025 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/lib/iwd/iwd...

This GDB supports auto-downloading debuginfo from the following URLs:
  <https://debuginfod.archlinux.org>
Enable debuginfod for this session? (y or [n]) n
Debuginfod has been disabled.
To make this setting permanent, add 'set debuginfod enabled off' to .gdbinit.
(No debugging symbols found in /usr/lib/iwd/iwd)
[New LWP 521]
--Type <RET> for more, q to quit, c to continue without paging--
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Core was generated by `/usr/lib/iwd/iwd'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00005616ad9f14fc in ?? ()
(gdb) bt
#0  0x00005616ad9f14fc in ?? ()
#1  0x00005616ada40c2c in ?? ()
#2  0x00007fb576d3e5ef in ?? () from /usr/lib/libell.so.0
#3  0x00007fb576d3e8a6 in l_notifylist_notify_matches () from /usr/lib/libell.so.0
#4  0x00007fb576cf787b in ?? () from /usr/lib/libell.so.0
#5  0x00007fb576ce825f in ?? () from /usr/lib/libell.so.0
#6  0x00007fb576ced4d5 in l_main_iterate () from /usr/lib/libell.so.0
#7  0x00007fb576ced93e in l_main_run () from /usr/lib/libell.so.0
#8  0x00007fb576cef2e6 in l_main_run_with_signal () from /usr/lib/libell.so.0
#9  0x00005616ad9d2e15 in ?? ()
#10 0x00007fb576a27781 in ?? () from /usr/lib/libc.so.6
#11 0x00007fb576a278b9 in __libc_start_main () from /usr/lib/libc.so.6
#12 0x00005616ad9d36d5 in ?? ()
(gdb)

Ist das irgendwie hilfreich?

GerBra

Dakuan Wie kann ich das feststellen? Networkmanager habe ich nicht bewusst installiert.

Zeige mal:
find /etc/systemd -type l -exec test -f {} \; -print | awk -F'/' '{ printf ("%-40s | %s\n", $(NF-0), $(NF-1)) }' | sort -f
//Edit: Oder
systemctl list-unit-files --system --state enabled

Dakuan
coredumpctl debug 521
...
Ist das irgendwie hilfreich?

Für mich nicht (und ohne debugging symbole für Berufene wohl auch nicht).
Besser:

GerBra Evtl. interessant wäre auch der komplette Zusammenhang im Journal wenn dieser segfault/coredump passiert.

//Edit2: Falls es dir nicht möglich ist, den Netzwerk-Teil (mit iwd) im Zusammenhang bis ein ppar Zeilen nach dem segfault verwertbar rauszufiltern, dann stelle am besten das komplette Journal für diesen Boot in dem das passiert auf einen Pastbin-Server und verlinke es hier.

Dakuan

[manfred@noir ~]$ systemctl list-unit-files --system --state enabled
UNIT FILE                          STATE   PRESET  
cups.path                          enabled disabled
acpid.service                      enabled disabled
avahi-daemon.service               enabled disabled
cups.service                       enabled disabled
getty@.service                     enabled enabled 
iwd.service                        enabled disabled
lightdm.service                    enabled disabled
NetworkManager-dispatcher.service  enabled disabled
NetworkManager-wait-online.service enabled disabled
NetworkManager.service             enabled disabled
systemd-timesyncd.service          enabled enabled 
avahi-daemon.socket                enabled disabled
cups.socket                        enabled disabled
systemd-userdbd.socket             enabled enabled 
remote-fs.target                   enabled enabled 
fstrim.timer                       enabled disabled

16 unit files listed.
[manfred@noir ~]$

Ja, NetworkManager ist da und meckert im Journal auch ziemlich viel herum. Das Journal für heute enthält ca. 3400 Zeilen und enthält auch mehrere Core-Dumps. Firefox hat kurz nach dem Aufwecken des PCs einige Male Die Netzwerkverbindung angemeckert. Das muss ich mir mal genauer ansehen. Ich weiß nicht, ob ich das heute noch schaffe.

GerBra

Dakuan Ja, NetworkManager ist da und meckert im Journal auch ziemlich viel herum

Die Ursache für das "viele meckern" ist wohl, daß du sowohl den Networkmanager(.service) und den iwd(.service) gleichzeitig als Services startest. Du mußt dich für eines entscheiden:

NetworkManager ("Komplettlösung")
Für WiFi-Verbindungen kann dieser als Wifi-Backend entweder wpa_supplicant(default) oder iwd nutzen¹. Der NM startet diese Backends aber selbständig. Deshalb ist es falsch, wpa_supplicant oder iwd (wie bei dir) als eigenen Service aktiv(enabled) zu haben.
Oder halt:
iwd (als Service)²
iwd (und wpa_supplicant als Gegenstück) sind für WiFi adäquat wie das "Einstecken vom Netzkabel" bei Ethernet. Die kümmern sich also um den "Link". I.d.R. braucht es dann ein separates Tool um die IP-Konfiguration(DHCP oder statische IPs, Routing, Nameserver) einzustellen oder zu beziehen.
iwd kann in den aktuellen Versionen allerdings auch die IP-Konfiguration handhaben, ist also auch eine "Komplettlösung"

Aber halt nicht beide Services aktiv haben...
Meiner Meinung spricht für NetworManager das Frontend("Applet im Systray", wer darauf Wert legt) und darüber die einfache Konfiguration bei oft wechselnden Umgebungen/Netzwerke. Also z.B. mobiler Laptop.
Wenn das Gerät per WLan allerdings immer am gleichen Platz/Netz ist (immer Zuhause, immer gleiche Konfig), dann kann das gesamte WiFi-Netzwerk-Handling auch über iwd geregelt werden.

Du mußt aktuell also einen der Services disablen. Alle NetworkManager*.services oder den iwd.service. Wenn beide gleichzeitig als Service aktiv sind dann konkurrieren diese um das WLan-Device und um den Link/IP-Config.

¹ https://wiki.archlinux.org/title/NetworkManager#Using_iwd_as_the_Wi-Fi_backend
² https://wiki.archlinux.org/title/Iwd

Dakuan

Da habe ich noch einiges zu lesen. Jedenfalls habe ich iwd heute erstmal disabled.

Warum ich iwd auf dem Rechner habe, kann ich nicht genau sagen. Beim ersten Arch Installationsversuch funktionierte ja fast gar nichts. Deshalb hatte ich dann Debian installiert und festgestellt, dass es nicht an der Hardware liegt. Vermutlich kam das durch das U-Tube Video. Meine Aufzeichnungen beginnen erst als alles halbwegs lief.

Ich verstehe aber nicht, warum das Problem erst viel später aufgetreten ist. Kann es sein, dass iwd nach dem Update schneller in die Hufe kommt und es dadurch zu Komplikationen kommt?

Trotzdem denke ich, das ein Programm nicht einfach so mit SIGSEGV abstürzen sollte.

Heute ist der Rechner übrigens ohne Probleme gestartet. Mal sehen ob es so bleibt.

Datenschutz
Impressum