Ankündigung

**Smurf** · 30.10.2025, 10:42

Allgemeine Hinweise:

journalctl | grep knxd ist Käse. Bitte journalctl -u knxd verwenden.

Außerdem: Logging einschalten. -t 0xffe -u /tmp/eib.

In deinem speziellen Fall:

Debian räumt inzwischen /tmp auf. Platziere den Socket bitte unter /run/knx oder so. Bzw. eigentlich sollte er da eh sein, siehe systemd/knxd.socket.

**Tru** · 30.10.2025, 11:44

Zitat von Smurf Beitrag anzeigen

Platziere den Socket bitte unter /run/knx oder so. Bzw. eigentlich sollte er da eh sein, siehe systemd/knxd.socket.

Jein. systemd/knxd.socket wird seit mindestens 10 Jahren definiert über Source systemd/knxd.socket.in als

Code:

[Socket]
ListenStream=@RUNDIR@/knx
ListenStream=6720

und ebenfalls bei Source systemd/knxd-net.socket.in als

Code:

[Socket]
FileDescriptorName=knxnet
ListenStream=@RUNDIR@/knxnet
SocketGroup=knxd
SocketMode=0660
Service=knxd.service

und RUNDIR wird seit ebensfalls mindestens 10 Jahren gesetzt durch Source m4/paths.m4 als

Code:

dnl Not part of a ./configure option, does LSB define it?
RUNDIR="/var/run"
AC_SUBST(RUNDIR)

Daher wird ListenStream=/var/run/knx resp ListenStream=/var/run/knxnet gesetzt. Wobei dann aber /var/run "überall" ein Softlink auf /run ist. Funktional ist es somit in /run aber in den Systemd Files wird im Original effektiv /var/run definiert.

**rdorsch** · 30.10.2025, 12:14

Vielen Dank für die super schnelle Antwort.

Dass Debian in /tmp aufräumt, ist ein guter Hinweis, vermute darin liegt die Ursache. /tmp/eib ist ein Legacy Setting, das einige Debian Upgrades in der Zwischenzeit überstanden hat.

In /run finde ich

Code:

root@home:/run# file knx
knx: socket
root@home:/run# file knxnet
knxnet: socket
root@home:/run#

Ich nehme an, der erste Socket ist ein Sideband Interface für die Kommunikation mit knxd, der zweite Socket ist für KNXIP Traffic (?).

Ich nehme an, Du meinst /run/knx. Jedenfalls startet bei mir knxd mit /run/knxd nicht:

Code:

KNXD_OPTS="-e 15.15.241 -E 4.0.1:8 -u /run/knxd -B single --send-delay=70 -b ipt:mdt"

und liefert:

Code:

Oct 30 11:35:06 home systemd[1]: Stopping knxd.service - KNX Daemon...
Oct 30 11:35:06 home systemd[1]: knxd.service: Deactivated successfully.
Oct 30 11:35:06 home systemd[1]: Stopped knxd.service - KNX Daemon.
Oct 30 11:35:06 home systemd[1]: Starting knxd.service - KNX Daemon...
Oct 30 11:35:06 home knxd[2449]: Layer 3 [16:A.unix/local         0.000] registerLink: 16:A.unix
Oct 30 11:35:06 home knxd[2449]: Layer 3 [16:A.unix/local         0.002] Start: cfg:A.unix
Oct 30 11:35:06 home knxd[2449]: Layer 5 [16:A.unix/local         0.002] down => >up
Oct 30 11:35:06 home knxd[2449]: Layer 8 [16:A.unix/local         0.002] OpenLocalSocket /run/knxd
Oct 30 11:35:06 home knxd[2449]: E00000017: [16:A.unix] OpenLocalSocket /run/knxd: listen: Invalid argument
Oct 30 11:35:06 home knxd[2449]: Layer 8 [16:A.unix/local         0.002] StopServer
Oct 30 11:35:06 home knxd[2449]: Layer 5 [16:A.unix/local         0.002] >up => error
Oct 30 11:35:06 home knxd[2449]: Layer 4 [16:A.unix/local         0.002] link state changed: error
Oct 30 11:35:06 home knxd[2449]: Layer 4 [16:A.unix/local         0.002] link state changed: error
Oct 30 11:35:06 home knxd[2449]: F00000105: [16:A.unix] Link down, terminating
Oct 30 11:35:06 home knxd[2449]: Layer 4 [16:A.unix/local         0.003] R Stopping
Oct 30 11:35:06 home knxd[2449]: Layer 5 [16:A.unix/local         0.003] error => >down
Oct 30 11:35:06 home knxd[2449]: Layer 4 [16:A.unix/local         0.003] link state changed: error
Oct 30 11:35:06 home knxd[2449]: Layer 8 [16:A.unix/local         0.003] StopServer
Oct 30 11:35:06 home systemd[1]: Started knxd.service - KNX Daemon.
Oct 30 11:35:06 home systemd[1]: knxd.service: Main process exited, code=exited, status=1/FAILURE
Oct 30 11:35:06 home systemd[1]: knxd.service: Failed with result 'exit-code'.

Wenn ich die -u Option ganz rausnehme (steht ja auch ganz unten in /etc/knxd.conf), start knxd wieder.

Allerdings kommt das Problem auch wieder zurück:

Code:

sh@home:~$ knxtool groupswrite ip:127.0.0.1 1/5/0 0
Connect failed: Connection reset by peer
sh@home:~$

Hier ist der dazugehörige knxd trace (journalctl -u knxd -S 11:42 > knxd.trace)

https://bokomoko.de/~rd/knxd/2025-10...-42-knxd.trace

**rdorsch** · 30.10.2025, 12:19

Zitat von Tru Beitrag anzeigen

Jein. systemd/knxd.socket wird seit mindestens 10 Jahren definiert über Source systemd/knxd.socket.in

Ich meine, ich habe das System 2017 zum ersten Mal installiert, warum ich damals /tmp/eib genommen habe weiß ich allerdings nicht mehr 😁 . Vermutlich habe ich es aus einer Installation von 2016 übernommen.... 🙃

**rdorsch** · 30.10.2025, 12:25

Es scheint als würde sich ein laufender Busmonitor

$ knxtool vbusmonitor1 ip:localhost

nicht mehr mit einem groupswrite über knxtool vertragen:

$ knxtool groupswrite ip:127.0.0.1 1/5/0 0

Mit vbusmonitor1 starten und stoppen kann ich den Fehler provozieren und wieder verschwinden lassen.

Mit -u /tmp/eib als knxd Option tritt das Problem nicht auf (ich vermute zumindest solange Debian /tmp nicht aufräumt).

**rdorsch** · 30.10.2025, 13:56

Zitat von rdorsch Beitrag anzeigen

Dass Debian in /tmp aufräumt, ist ein guter Hinweis, vermute darin liegt die Ursache.

Hat sich wahrscheinlich als falsche Spur erwiesen:

Code:

root@home:/etc# cat /etc/tmpfiles.d/tmp.conf
D /tmp 1777 root root -
root@home:/etc#

Konfiguriert das Aufräumen und das "-' am Ende verstehe ich so, dass die Dateien unendlich bzw. bis zum nächsten Reboot überleben.

Als Referenz falls noch jemand über das Thema stolpern sollte:

https://www.debian.org/releases/stab...ularly-cleaned

Ich habe jetzt nochmal nach /tmp/eib zurückkonfiguriert und beobachte, ob die Datei verschwindet.

Bin jedoch trotzdem daran interessiert, zu verstehen, warum vbusmonitor1 ein groupswrite blockiert, wenn ich ohne -u /tmp/eib laufe.

**Tru** · 30.10.2025, 22:22

Zitat von rdorsch Beitrag anzeigen

Bin jedoch trotzdem daran interessiert, zu verstehen, warum vbusmonitor1 ein groupswrite blockiert, wenn ich ohne -u /tmp/eib laufe.

Das würde mich auch interessieren. Ich selber habe knxd noch nie mit -u genutzt, sondern immer via den knxd.socket und dabei nie dein beschriebenes Problem gesehen. Das ist definitiv nicht normal.

Ich bin produktiv auf der Ubuntu Schiene. Auf meinem Test Debian 12 läuft das aber ebenso problemlos. Vielleicht komme ich übers Wochenende mal dazu, das auf einem Debian 13 nachzustellen.

**rdorsch** · 30.10.2025, 22:52

Auf Debian 12 habe ich das Problem auch nicht gesehen. Ich wüsste auch nicht, was ich an der KNX Konfiguration geändert haben könnte. Zur Sicherheit habe ich mir die Änderungen in der knxd.conf Datei im etckeeper nochmal angeschaut, die während dem Update passiert sind, aber hier sind nur Kommentarzeilen betroffen:

Code:

diff --git a/knxd.conf b/knxd.conf
index 83a65a60..effa1e41 100644
--- a/knxd.conf
+++ b/knxd.conf
@@ -1,15 +1,9 @@
 # configuration for knxd.service
-#KNXD_OPTS="-e 0.0.1 -E 0.0.2:8 -u /tmp/eib -b ip:"
+# KNXD_OPTS="-e 0.0.1 -E 0.0.2:8 -u /tmp/eib -b ip:"
 
 # mdt
 KNXD_OPTS="-e 15.15.241 -E 4.0.1:8 -u /tmp/eib -B single --send-delay=70 -b ipt:mdt"
 
-# mdt backup
-# KNXD_OPTS="-e 15.15.247 -E 4.0.1:8 -u /tmp/eib -B single --send-delay=70 -b ipt:mdt-backup"
-
-# Default: should work with MDT SCN-IP000.02 IP Interface w/o any programming
-#KNXD_OPTS="-e 15.15.241 -E 4.0.1:8 -u /tmp/eib -B single --send-delay=70 -b ipt:192.168.5.179"
-
 # configuration for knxd.service using new configuration format in /etc/knxd.ini
 # use only this line if you used knxd_args to convert your old startup options
 # KNXD_OPTS=/etc/knxd.ini
@@ -20,8 +14,10 @@ KNXD_OPTS="-e 15.15.241 -E 4.0.1:8 -u /tmp/eib -B single --send-delay=70 -b ipt:
 #  multicast client (-b ip:).
 # knxd's own bus address is 0.0.1; it will assign 0.0.2…0.0.9 to clients.
 # The knxd.socket file also tells knxd to listen to
-#  /run/eib (socket activation via systemd)
+#  /run/knx (socket activation via systemd)
 #  TCP port 6720 (socket activation via systemd)
+# The knxd-net.socket file also tells knxd to listen for KNXnet/ip connection on
+#  /run/knxnet (socket activation via systemd)
 # You *need* the -e option. Clients cannot connect without "-E".
 
 # You can read knxd's logs with

Habe mal gemini nach dem Thema befragt und seine Antwort hat impliziert, dass die Zahl der freien Tunneling-Slots das Problem verursachen kann. Ich habe diese dann experimentell von 8 auf 16 erhöht und ich habe das Problem erstmal nicht mehr gesehen. Jetzt habe ich gerade gedacht, bevor ich Unsinn schreibe, versuche ich das Problem mit 8 Tunnelling Slots nochmal zu reproduzieren. Leider bekomme ich es damit gerade aber auch nicht mehr reproduziert. Da ich die Ursache nicht verstanden und beseitigt habe, befürchte ich, dass das Problem bald zurück kommt (in meist in schlechtesten Moment ;-)). Ich lasse jetzt erstmal weiterlaufen.

Warum 8 tunneling slots bei meinem Setup nicht reichen sollten kann ich im Moment auch nicht nachvollziehen.

Hier noch der Vollstandigkeit halber, was Gemini auf die Frage "Blockiert knxtool vbusmonitor1 einen der Sockets?" (Kontext aus vorangegangener Frage: /run/knx und /run/knxnet) geantwortet hat (klingt zumindest erstmal plausibel für mich, wenn Unsinn dabei ist, bitte kommentieren, vielleicht hilft es ja bei der Eingrenzung des Fehlers):

Knxtool vbusmonitor1 (oder das allgemeinere knxtool monitor) blockiert nicht direkt einen der Sockets wie /run/knx oder /run/knxnet. Stattdessen stellt es eine Verbindung zu einem dieser Sockets her, um alle Telegramme auf dem KNX-Bus mitzulesen.

Wenn knxd korrekt konfiguriert ist, unterstützt es gleichzeitig mehrere Verbindungen über seine Sockets.

🔄 Funktionsweise von knxtool und knxd
Der knxd dient als Server, der die Verbindung zum physischen KNX-Bus verwaltet. Die Sockets (/run/knx, /run/knxnet, etc.) sind die Zugangspunkte für Client-Anwendungen:

knxd (Daemon): Er ist so konzipiert, dass er multi-user-fähig ist. Er kann gleichzeitig mit ETS, Visualisierungen (wie OpenHAB oder FHEM) und Tools (wie knxtool) kommunizieren.

knxtool vbusmonitor1: Dieses Tool agiert als Client und nutzt einen freien Tunneling-Slot (Verbindungsadresse) über den Unix Domain Socket (z.B. /run/knx), um die Busaktivität zu abonnieren. Es belegt dabei einen dieser Slots, aber blockiert nicht den gesamten Socket oder verhindert andere Verbindungen.

⚠️ Wichtige Unterscheidung
Die Sockets selbst sind nur die Eingangstüren zum knxd. Sie sind nicht das Nadelöhr. Das Limit liegt in der Regel bei der Anzahl der maximal möglichen Tunneling-Verbindungen (Slots), die der knxd oder das zugrundeliegende KNX-IP-Interface zulassen.

Die Standardeinstellung von knxd sieht typischerweise eine Reihe von Adressen für Clients vor (z.B. durch die Option -E 1.1.2:8, was 8 Tunneling-Slots von 1.1.2 bis 1.1.9 bereitstellt).

Jeder Client (wie knxtool, ETS, Home Assistant) belegt einen dieser Slots.

Wenn Sie vbusmonitor1 starten, wird ein Slot belegt. Solange noch freie Slots verfügbar sind, können sich andere Clients weiterhin verbinden. Erst wenn alle verfügbaren Slots belegt sind, würde ein weiterer Verbindungsversuch (auch durch ein anderes Tool) fehlschlagen, was oft mit der Fehlermeldung "Connection refused" oder "No free address" quittiert wird.

**rdorsch** · Gestern, 10:34

Auf Debian 12 habe ich das Problem auch nicht gesehen. Ich wüsste auch nicht, was ich an der KNX Konfiguration geändert haben könnte. Zur Sicherheit habe ich mir die Änderungen in der knxd.conf Datei im etckeeper nochmal angeschaut, die während dem Update passiert sind, aber hier sind nur Kommentarzeilen betroffen:

Code:

diff --git a/knxd.conf b/knxd.conf
index 83a65a60..effa1e41 100644
--- a/knxd.conf
+++ b/knxd.conf
@@ -1,15 +1,9 @@
 # configuration for knxd.service
-#KNXD_OPTS="-e 0.0.1 -E 0.0.2:8 -u /tmp/eib -b ip:"
+# KNXD_OPTS="-e 0.0.1 -E 0.0.2:8 -u /tmp/eib -b ip:"
 
 # mdt
 KNXD_OPTS="-e 15.15.241 -E 4.0.1:8 -u /tmp/eib -B single --send-delay=70 -b ipt:mdt"
 
-# mdt backup
-# KNXD_OPTS="-e 15.15.247 -E 4.0.1:8 -u /tmp/eib -B single --send-delay=70 -b ipt:mdt-backup"
-
-# Default: should work with MDT SCN-IP000.02 IP Interface w/o any programming
-#KNXD_OPTS="-e 15.15.241 -E 4.0.1:8 -u /tmp/eib -B single --send-delay=70 -b ipt:192.168.5.179"
-
 # configuration for knxd.service using new configuration format in /etc/knxd.ini
 # use only this line if you used knxd_args to convert your old startup options
 # KNXD_OPTS=/etc/knxd.ini
@@ -20,8 +14,10 @@ KNXD_OPTS="-e 15.15.241 -E 4.0.1:8 -u /tmp/eib -B single --send-delay=70 -b ipt:
 #  multicast client (-b ip:).
 # knxd's own bus address is 0.0.1; it will assign 0.0.2…0.0.9 to clients.
 # The knxd.socket file also tells knxd to listen to
-#  /run/eib (socket activation via systemd)
+#  /run/knx (socket activation via systemd)
 #  TCP port 6720 (socket activation via systemd)
+# The knxd-net.socket file also tells knxd to listen for KNXnet/ip connection on
+#  /run/knxnet (socket activation via systemd)
 # You *need* the -e option. Clients cannot connect without "-E".
 
 # You can read knxd's logs with

Habe mal gemini nach dem Thema befragt und seine Antwort hat impliziert, dass die Zahl der freien Tunneling-Slots das Problem verursachen kann. Ich habe diese dann experimentell von 8 auf 16 erhöht und ich habe das Problem erstmal nicht mehr gesehen. Jetzt habe ich gerade gedacht, bevor ich Unsinn schreibe, versuche ich das Problem mit 8 Tunnelling Slots nochmal zu reproduzieren. Leider bekomme ich es damit gerade aber auch nicht mehr reproduziert. Da ich die Ursache nicht verstanden und beseitigt habe, befürchte ich, dass das Problem bald zurück kommt (in meist in schlechtesten Moment ;-)). Ich lasse jetzt erstmal weiterlaufen.

Warum 8 tunneling slots bei meinem Setup nicht reichen sollten kann ich im Moment auch nicht nachvollziehen.

Hier noch der Vollstandigkeit halber, was Gemini auf die Frage "Blockiert knxtool vbusmonitor1 einen der Sockets?" (Kontext aus vorangegangener Frage: /run/knx und /run/knxnet) geantwortet hat (klingt zumindest erstmal plausibel für mich, wenn Unsinn dabei ist, bitte kommentieren, vielleicht hilft es ja bei der Eingrenzung des Fehlers):

Knxtool vbusmonitor1 (oder das allgemeinere knxtool monitor) blockiert nicht direkt einen der Sockets wie /run/knx oder /run/knxnet. Stattdessen stellt es eine Verbindung zu einem dieser Sockets her, um alle Telegramme auf dem KNX-Bus mitzulesen.

Wenn knxd korrekt konfiguriert ist, unterstützt es gleichzeitig mehrere Verbindungen über seine Sockets.

🔄 Funktionsweise von knxtool und knxd
Der knxd dient als Server, der die Verbindung zum physischen KNX-Bus verwaltet. Die Sockets (/run/knx, /run/knxnet, etc.) sind die Zugangspunkte für Client-Anwendungen:

knxd (Daemon): Er ist so konzipiert, dass er multi-user-fähig ist. Er kann gleichzeitig mit ETS, Visualisierungen (wie OpenHAB oder FHEM) und Tools (wie knxtool) kommunizieren.

knxtool vbusmonitor1: Dieses Tool agiert als Client und nutzt einen freien Tunneling-Slot (Verbindungsadresse) über den Unix Domain Socket (z.B. /run/knx), um die Busaktivität zu abonnieren. Es belegt dabei einen dieser Slots, aber blockiert nicht den gesamten Socket oder verhindert andere Verbindungen.

⚠️ Wichtige Unterscheidung
Die Sockets selbst sind nur die Eingangstüren zum knxd. Sie sind nicht das Nadelöhr. Das Limit liegt in der Regel bei der Anzahl der maximal möglichen Tunneling-Verbindungen (Slots), die der knxd oder das zugrundeliegende KNX-IP-Interface zulassen.

Die Standardeinstellung von knxd sieht typischerweise eine Reihe von Adressen für Clients vor (z.B. durch die Option -E 1.1.2:8, was 8 Tunneling-Slots von 1.1.2 bis 1.1.9 bereitstellt).

Jeder Client (wie knxtool, ETS, Home Assistant) belegt einen dieser Slots.

Wenn Sie vbusmonitor1 starten, wird ein Slot belegt. Solange noch freie Slots verfügbar sind, können sich andere Clients weiterhin verbinden. Erst wenn alle verfügbaren Slots belegt sind, würde ein weiterer Verbindungsversuch (auch durch ein anderes Tool) fehlschlagen, was oft mit der Fehlermeldung "Connection refused" oder "No free address" quittiert wird.

**rdorsch** · Gestern, 10:47

Tru Herzlichen Dank für Deine Bereitschaft einen Test mit Debian 13 zu machen, ist aber mit sehr hoher Wahrscheinlichkeit nicht mehr notwendig, denn ich habe das Problem wahrscheinlich gelöst:

Gemini hatte vermutlich recht, mir sind die Tunneling-Slots ausgegangen.

Was ist passiert: Im Zuge des Updates auf Debian 13 musste ich ein paar Skripte anpassen, das sich einige APIs (pymodbus, mqtt) geändert haben. In dem Zug habe ich auch eine KNX Gruppenadresse (in ETS) umgezogen. Dabei habe ich leider die Adresse in einem knxtool read übersehen.

$ knxtool read ip:localhost 5/3/50

kommt dann nicht zurück und blockiert einen Tunneling-Slot. Irgendwann sind dann keine mehr frei. Je nachdem, welche Operation den letzten Tunneling slot belegt hat (z.B. vbusmonitor1) bzw. keinen mehr bekommen hat, war das Fehlerbild dann leider auch nicht einheitlich oder reproduzierbar.

Ein Timeout in der read Operation in knxtool wäre hier sehr hilfreich gewesen: Damit wäre nur die fehlerhafte Funktion kaputt gegangen und nicht der gesamte Socket blockiert gewesen. Der Fehler wäre erst später aufgefallen, aber das Debugging wäre viel einfacher gewesen.

Falls die Implementierung eines Timeouts in knxtool komplex sein sollte, wäre auch schon eine Möglichkeit die freien oder belegten Tunneling-Slots abzufragen hilfreich.

Vielen Dank nochmal für Eure Unterstützung Tru, Smurf , @gemini .

Ankündigung

knxd instabil nach Debian Update

knxd instabil nach Debian Update

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar

Kommentar