[Bug] sonewconn in `dmesg` while using Budgie

[littlelevi]

Description

My dmesg get spammed while using Budgie desktop. The buffer is literally filled out with it.

sonewconn: pcb 0xfffff80010292400 (local:/var/run/devd.seqpacket.pipe): Listen queue overflow: 1 already in queue awaiting acceptance (58 occurrences), euid 0, rgid 0, jail 0
sonewconn: pcb 0xfffff80010292400 (local:/var/run/devd.seqpacket.pipe): Listen queue overflow: 1 already in queue awaiting acceptance (59 occurrences), euid 0, rgid 0, jail 0
sonewconn: pcb 0xfffff80010292400 (local:/var/run/devd.seqpacket.pipe): Listen queue overflow: 1 already in queue awaiting acceptance (58 occurrences), euid 0, rgid 0, jail 0
sonewconn: pcb 0xfffff80010292400 (local:/var/run/devd.seqpacket.pipe): Listen queue overflow: 1 already in queue awaiting acceptance (58 occurrences), euid 0, rgid 0, jail 0
sonewconn: pcb 0xfffff80010292400 (local:/var/run/devd.seqpacket.pipe): Listen queue overflow: 1 already in queue awaiting acceptance (58 occurrences), euid 0, rgid 0, jail 0
sonewconn: pcb 0xfffff80010292400 (local:/var/run/devd.seqpacket.pipe): Listen queue overflow: 1 already in queue awaiting acceptance (59 occurrences), euid 0, rgid 0, jail 0

It only happens when I'm logged into Budgie. Under Gnome desktop, it doesn't happen. It also doesn't happen when I'm logged out of X. Maybe some notifier is spamming devd

Budgie version

10.8.2

Operating System

FreeBSD 14.0-RELEASE-p3

Steps to reproduce the issue

Compile Budgie from ports. Log in to budgie desktop(in my case using lightdm), open terminal and check dmesg No application is needed, either in autostart or running. Just terminal emulator.

Actual result

So far, the only problem is that I can't comfortably view my dmesg. But spamming the daemon that handle devices, can't be a good thing. So far, I haven't noticed any major problems, which doesn't mean they aren't there.

Expected result

No previously mentioned spam in dmesg

Additional information

As far as I know, under FreeBSD, devd perform the same function to udev under Linux. X org under FreeBSD is compiled with https://www.freshports.org/devel/libudev-devd providing common interface between these two. This may be edge case related only to FreeBSD, but Linux may have similar behavior. It is possible that udev is smarter than devd providing protection against such things.

[JoshStrobl]

Budgie Desktop doesn't directly use udev. You may want to check some of the following since this seems to be common in the BSDs:

• https://forums.freebsd.org/threads/sonewconn-pcb-0xfffff800463fc000-listen-queue-overflow.68674/
• https://forum.netgate.com/topic/178995/pfsense-panic-after-sonewconn-pcb-address-listen-queue-overflow
• https://forums.freebsd.org/threads/sonewconn-pcb-0xff-listen-queue-overflow-already-in-queue-awaiting-acceptance.54597/
• https://www.truenas.com/community/threads/issues-with-this-error-freenas-kernel-sonewconn-pcb-0xfffff801c8f631d0-listen-queue-overflow.74245/

Closing pending details that indicate it's an actual Budgie issue. Feel free to re-open if you see any indication that it's a budgie process specifically. Thanks!

[littlelevi]

I already checked that links. Foremost. All your links are related to networking. Systems like True NAS is also based on FreeBSD. That's true that FreeBSD has rather conservative kernel knobs. For heavy load, those values mentioned in those posts must be increased. But we are not talking about servers.

Notice. Here we are talking about devd local devd daemon that handles local devices, and local pipe. Not TCP/IP connections from outside, as in your links. Local process is hitting local devd really hard. Something is saturating devd queue. And trust me, I don't have 10 mouses and 50 mass storage hooked on.

"Budgie Desktop doesn't directly use udev" I would be surprised if it would. But somehow, how Budgie handles devices could affect devd. But at the same time, it doesn't udev in Linux.

Here are key points.

1. My box is not a server, not even sshd is enabled.
2. The problem does not occur when X Org is not running
3. The problem does not occur when using Gnome-Desktop
4. The problem does not occur when using XFCE4

If it's not Budgie, then I don't know what else it could be. It has to be Budgie or one of it component that is not present in/together with both XFCE4 or Gnome or outside Xorg. I checked and used them on clean sessions.

I don't know how to investigate in more detail. But my hunch is on libinput. Or whatever/how Budgie handles Keyboard and Mouses. That's my best guess.

XFCE4, Gnome and Budgie were compiled in the same time, against the same shared libs. This means that perhaps more important is how they are used in the code, rather than their version.

That's the best info I can provide, at least right now.