Again, you're quick to misinterpret me. My responses were directly tied to all of the OP's Q&A.
pietinger wrote:I am also on OpenRC (with KDE/Plasma) and dont have this problem ... even with a manually configured kernel WITHOUT CONFIG_NET_SCHED enabled ... because there is no file with this setting.
I had the hope that someone knows which package installs such a file ... if it is unknown we should search in all directories ... e.g. ->
Code: Select all
# grep "" /usr/lib/sysctl.d/*
/usr/lib/sysctl.d/00protected-links.conf:fs.protected_symlinks = 1
/usr/lib/sysctl.d/00protected-links.conf:fs.protected_hardlinks = 1
/usr/lib/sysctl.d/40-ping_group_range.conf:# ping(8) without CAP_NET_ADMIN and CAP_NET_RAW
/usr/lib/sysctl.d/40-ping_group_range.conf:# The upper limit is set to 2^31-1. Values greater than that get rejected by
/usr/lib/sysctl.d/40-ping_group_range.conf:# the kernel because of this definition in linux/include/net/ping.h:
/usr/lib/sysctl.d/40-ping_group_range.conf:# #define GID_T_MAX (((gid_t)~0U) >> 1)
/usr/lib/sysctl.d/40-ping_group_range.conf:-net.ipv4.ping_group_range = 0 2147483647
First, why would the DE/WM environment, if any, matter here? It is largely irrelevant.
I have the exact same output. I don't think this was a useful endeavor, arguably any more than the more exhaustive one I did below before posting the kernel menu mention, which is exactly why I posted it. OP is using openrc like us, not the larger response with someone running systemd which went in some other direction. OP had already directly/indirectly by us (again, why?) both been given mention for locations to try to grep in fishing for a needle in the haystack, file wise.
Follow-ups mentioned bugs referencing net_sch_* missing selection associations. The fifo one aforementioned that OP showed as the default set should have been the one I mentioned in the kernel settings that
selects that. I have that and only that:
Code: Select all
amd300 /usr/src/linux # grep -i "_net.sch.*[ym]$" .config
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_FIFO=y
amd300 /usr/src/linux # grep -iR 'net\.core' /proc/sys /etc/sysctl.d/ /run/sysctl.d/ /usr/local/lib/sysctl.d/ /usr/lib/sysctl.d/ /lib/sysctl.d/ /etc/ 2>/dev/null
amd300 /usr/src/linux #
amd300 /usr/src/linux # grep -iR 'pfifo' /proc/sys /etc/sysctl.d/ /run/sysctl.d/ /usr/local/lib/sysctl.d/ /usr/lib/sysctl.d/ /lib/sysctl.d/ /etc/ 2>/dev/null
/proc/sys/net/core/default_qdisc:pfifo_fast
amd300 /usr/src/linux #
It takes a few seconds to toggle that kernel config entry or to at least check what you have set under same, rebuild if needed and test.
Instead, we're assuming an open syscall failure because of the error message. Which is fine, if it's on your end to debug, which neither you nor I have the OP's failure to test; nor am I seeing any related reference to same in the expected aforementioned locations. The only .*net.*fifo.* entry I have in my .config settings is via the above, which the kernel setup explains why it got selected. The bug reports refer to 1 other maybe
related net_sch_ as well in trying to make a determination or establish a pattern behind troubleshooting the issue(s). Occam's Razor. Sysctl is about affecting kernel settings at runtime, which can mean issues are as much about kernel configuration issues than any .conf file concerns.
The output shown here and Q&A responses from the OP are exactly why I responded as I did to aid in troubleshooting.