Describe the bug:
Occasionally, some software suddenly stops working, as if the Internet went down.
After doing the whole diagnostic dance, I get to a point where I realize some things are still working normally but others don't. The exact way in which this materializes seems somewhat inconsistent.
In this last instance, a generic Deny 443 was automatically added while the computer was unattended, silently breaking a host of applications.
Instead of matching and applying the rules that already exist, which allow such apps outbound access, OpenSnitch prompts for the creation of a new, temporary one.
Regardless of the Pop-Up Configuration having the Default Target set to executable or command line, OpenSnitch left almost all parameters empty: the only one with a checkmark being "Port: 443".
Today I was "lucky" enough to have it happen to me several times in a row when I was in front of the computer, and when the pop-up came up and could see that the connection was attributed to something identified as dmx1:hls.
This was likely yt-dlp running in background, however neither the command line nor the executable were present. While I was writing this ticket, I got another instance in which the pop-up opened and yt-dlp was recognized explicitly (exposed in the title bar), however again other all fields were blank, bar the port.
PS: and now I have a new occurence of a yt-dlp pop-up with no strings but this time port 53, which would have killed name resolution on the machine.
An ALLOW rule for yt-dlp exists and has been working for a long time, and I'm not sure why this is surfacing only now in this shape:
- my /var/log/apt/history.log shows that I hadn't performed any action in the last 72 hours (during which yt-dlp and everything connecting to 443 worked normally)
- the latest yt-dlp version is 2026.07.04, so it hasn't been updated in a long time (mentioning because upgrades are handled through pipx rather than apt).
While I can't say what is making OpenSnitch fail to come up with command line and executable strings, the issue of random generic deny rules appearing with the computer unattended has been recurrent since I switched to Linux on the desktop, over 6 months: I originally installed the vastly outdated 1.6.9 package that came with my distribution, however even after replacing it with the 1.8.0 GitHub package, it's still appearing.
I tried searching the issues for a similar problem, but I was struggling to come up with relevant keywords and the ones I tried did not unearth anything relevant.
- OpenSnitch version:1.8.0-3 (GitHub deb) - but has been appearing since 1.6.9-3 (Debian package)
- OS: Debian amd64
- OS version: trixie 13.6
- Window Manager: KDE Plasma 6.3.6
- Kernel version: 7.0.13+deb13-amd64 #1 SMP PREEMPT_DYNAMIC Debian 7.0.13-1~bpo13+1 (2026-07-05)
To Reproduce:
I don't know. It just happens every once in a while and then everything goes back to normal until the next occurrence. I'm not rebooting the computer, since this time it might be possible to observe the bug again, and perform tests and further diagnostics.
For the time being, I have added rules that whitelist the relevant domains and should prevent generic 443 nukes from dropping.
Post error logs:
IMP Start writing logs to /var/log/opensnitchd.log
ERR Error adding audit rule, err32=exec: "auditctl": executable file not found in $PATH, err=exec: "auditctl": executable file not found in $PATH
ERR auditd Start() connection error dial unix: missing address
ERR Error deleting audit rules, err32=exec: "auditctl": executable file not found in $PATH, err64=exec: "auditctl": executable file not found in $PATH
WAR error starting audit monitor method: dial unix: missing address
ERR Reconf() -> Init() error: &{2 dial unix: missing address}
IMP Start writing logs to /var/log/opensnitchd.log
INF exit checking firewall rules
INF nftables config changed, reloading
INF fw configuration loaded
INF Starting new fw checker every 15s ...
INF Using nftables firewall
ERR Error adding audit rule, err32=exec: "auditctl": executable file not found in $PATH, err=exec: "auditctl": executable file not found in $PATH
ERR auditd Start() connection error dial unix: missing address
ERR Error deleting audit rules, err32=exec: "auditctl": executable file not found in $PATH, err64=exec: "auditctl": executable file not found in $PATH
WAR error starting audit monitor method: dial unix: missing address
INF Process monitor method /proc
ERR Reconf() -> Init() error: &{2 dial unix: missing address}
INF ProcEventMonitor started
ERR getting notifications: rpc error: code = Canceled desc = CANCELLED <nil>
INF Stop receiving notifications
ERR Connection to the UI service lost.
INF Connected to the UI service on ///tmp/osui.sock
IMP UI connected, dispathing queued alerts: 0
ERR Subscribing to GUI rpc error: code = Canceled desc = CANCELLED
ERR Connection to the UI service lost.
INF Connected to the UI service on ///tmp/osui.sock
IMP UI connected, dispathing queued alerts: 0
ERR Subscribing to GUI rpc error: code = Canceled desc = CANCELLED
ERR Connection to the UI service lost.
INF Connected to the UI service on ///tmp/osui.sock
IMP UI connected, dispathing queued alerts: 0
ERR Subscribing to GUI rpc error: code = Canceled desc = CANCELLED
ERR Connection to the UI service lost.
INF Connected to the UI service on ///tmp/osui.sock
IMP UI connected, dispathing queued alerts: 0
ERR Subscribing to GUI rpc error: code = Canceled desc = CANCELLED
ERR Connection to the UI service lost.
INF Connected to the UI service on ///tmp/osui.sock
IMP UI connected, dispathing queued alerts: 0
ERR Subscribing to GUI rpc error: code = Canceled desc = CANCELLED
ERR Connection to the UI service lost.
INF Connected to the UI service on ///tmp/osui.sock
IMP UI connected, dispathing queued alerts: 0
ERR Subscribing to GUI rpc error: code = Canceled desc = CANCELLED
ERR Connection to the UI service lost.
INF Connected to the UI service on ///tmp/osui.sock
IMP UI connected, dispathing queued alerts: 0
ERR Subscribing to GUI rpc error: code = Canceled desc = CANCELLED
ERR Connection to the UI service lost.
INF Connected to the UI service on ///tmp/osui.sock
IMP UI connected, dispathing queued alerts: 0
ERR Subscribing to GUI rpc error: code = Canceled desc = CANCELLED
ERR Connection to the UI service lost.
INF Connected to the UI service on ///tmp/osui.sock
IMP UI connected, dispathing queued alerts: 0
ERR Subscribing to GUI rpc error: code = Canceled desc = CANCELLED
ERR Connection to the UI service lost.
INF Connected to the UI service on ///tmp/osui.sock
IMP UI connected, dispathing queued alerts: 0
ERR Subscribing to GUI rpc error: code = Canceled desc = CANCELLED
ERR Connection to the UI service lost.
INF Connected to the UI service on ///tmp/osui.sock
IMP UI connected, dispathing queued alerts: 0
ERR Subscribing to GUI rpc error: code = Canceled desc = CANCELLED
ERR Connection to the UI service lost.
INF Connected to the UI service on ///tmp/osui.sock
IMP UI connected, dispathing queued alerts: 0
ERR Subscribing to GUI rpc error: code = Canceled desc = CANCELLED
ERR Connection to the UI service lost.
INF Connected to the UI service on ///tmp/osui.sock
IMP UI connected, dispathing queued alerts: 0
ERR Subscribing to GUI rpc error: code = Unavailable desc = transport is closing
ERR Connection to the UI service lost.
INF Connected to the UI service on ///tmp/osui.sock
IMP UI connected, dispathing queued alerts: 0
INF Start receiving notifications
IMP [tasks] Adding task: sockets-monitor
IMP Added new rule: deny if dest.port is '443'
INF [notification] delete rule: deny-12h-simple-443 17858747967236896
IMP Added new rule: deny if dest.port is '443'
INF [notification] delete rule: deny-12h-simple-443 17858761428895411
grepping journalctl I could see many messages along the lines of:
Timed out while sending packet to queue channel 3860565303
Which are probably unrelated, since they are not limited to the time of the issue.
Expected behavior (optional):
OpenSnitch should be recognizing the source binary correctly and apply the relevant rules instead of creating new ones.
Screenshots:
N/A
Additional context:
N/A
Describe the bug:
Occasionally, some software suddenly stops working, as if the Internet went down.
After doing the whole diagnostic dance, I get to a point where I realize some things are still working normally but others don't. The exact way in which this materializes seems somewhat inconsistent.
In this last instance, a generic Deny 443 was automatically added while the computer was unattended, silently breaking a host of applications.
Instead of matching and applying the rules that already exist, which allow such apps outbound access, OpenSnitch prompts for the creation of a new, temporary one.
Regardless of the Pop-Up Configuration having the Default Target set to executable or command line, OpenSnitch left almost all parameters empty: the only one with a checkmark being "Port: 443".
Today I was "lucky" enough to have it happen to me several times in a row when I was in front of the computer, and when the pop-up came up and could see that the connection was attributed to something identified as
dmx1:hls.This was likely yt-dlp running in background, however neither the command line nor the executable were present. While I was writing this ticket, I got another instance in which the pop-up opened and yt-dlp was recognized explicitly (exposed in the title bar), however again other all fields were blank, bar the port.
PS: and now I have a new occurence of a yt-dlp pop-up with no strings but this time port 53, which would have killed name resolution on the machine.
An ALLOW rule for yt-dlp exists and has been working for a long time, and I'm not sure why this is surfacing only now in this shape:
While I can't say what is making OpenSnitch fail to come up with command line and executable strings, the issue of random generic deny rules appearing with the computer unattended has been recurrent since I switched to Linux on the desktop, over 6 months: I originally installed the vastly outdated 1.6.9 package that came with my distribution, however even after replacing it with the 1.8.0 GitHub package, it's still appearing.
I tried searching the issues for a similar problem, but I was struggling to come up with relevant keywords and the ones I tried did not unearth anything relevant.
To Reproduce:
I don't know. It just happens every once in a while and then everything goes back to normal until the next occurrence. I'm not rebooting the computer, since this time it might be possible to observe the bug again, and perform tests and further diagnostics.
For the time being, I have added rules that whitelist the relevant domains and should prevent generic 443 nukes from dropping.
Post error logs:
grepping journalctl I could see many messages along the lines of:
Timed out while sending packet to queue channel 3860565303Which are probably unrelated, since they are not limited to the time of the issue.
Expected behavior (optional):
OpenSnitch should be recognizing the source binary correctly and apply the relevant rules instead of creating new ones.
Screenshots:
N/A
Additional context:
N/A