keyd failing at startup

Message

Section_8 · Post by **Section_8** » Thu Feb 12, 2026 1:03 pm

Hello,
Since re-installing gentoo about 3 months ago, I have been running app-misc/keyd from the guru overlay to remap a few keys. A couple of days ago, I discovered that it is failing at startup (openrc, /etc/init.d/keyd) with this:

Code: Select all

sched_setscheduler: Operation not permitted

After trying a number of different things, I discovered that if I boot gentoo-kernel-bin, it doesn't fail. My dist kernel:

Code: Select all

Linux officepc 6.12.63-gentoo-dist #1 SMP PREEMPT_DYNAMIC Thu Dec 18 19:15:56 -00 2025 x86_64 AMD Ryzen 7 5800X3D 8-Core Processor AuthenticAMD GNU/Linux

Booting the same version of gentoo-sources (customized .config), keyd fails with the sched_setscheduler error above:

Code: Select all

Linux officepc 6.12.63-gentoo #1 SMP PREEMPT_DYNAMIC Thu Feb 12 06:32:34 CST 2026 x86_64 AMD Ryzen 7 5800X3D 8-Core Processor AuthenticAMD GNU/Linux

So I am assuming that I need some kernel setting in my gentoo-sources .config for this, but looking around (man sched_setscheduler and such) hasn't helped. Any thoughts?

pingtoo · Post by **pingtoo** » Thu Feb 12, 2026 4:23 pm

check if you have CONFIG_RT_GROUP_SCHED enabled.

Post by **pietinger** » Thu Feb 12, 2026 4:58 pm

pingtoo wrote:check if you have CONFIG_RT_GROUP_SCHED enabled.

Hmmm ... realtime ... ?

I looked at the config of our dist-kernel:

Code: Select all

# grep "SCHED" dist-kernel-bin-config-6.18.5 
CONFIG_SCHED_CORE=y
CONFIG_SCHED_CLASS_EXT=y
CONFIG_HAVE_SCHED_AVG_IRQ=y
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_CGROUP_SCHED=y
CONFIG_GROUP_SCHED_WEIGHT=y
CONFIG_GROUP_SCHED_BANDWIDTH=y
CONFIG_FAIR_GROUP_SCHED=y
# CONFIG_RT_GROUP_SCHED is not set
CONFIG_EXT_GROUP_SCHED=y
CONFIG_SCHED_MM_CID=y
CONFIG_SCHED_AUTOGROUP=y
CONFIG_SCHED_OMIT_FRAME_POINTER=y
CONFIG_SCHED_MC_PRIO=y
CONFIG_SCHED_HRTICK=y
CONFIG_CPU_FREQ_DEFAULT_GOV_SCHEDUTIL=y
CONFIG_CPU_FREQ_GOV_SCHEDUTIL=y
CONFIG_ARCH_SUPPORTS_SCHED_SMT=y
CONFIG_ARCH_SUPPORTS_SCHED_CLUSTER=y
CONFIG_ARCH_SUPPORTS_SCHED_MC=y
CONFIG_SCHED_SMT=y
CONFIG_SCHED_CLUSTER=y
CONFIG_SCHED_MC=y
CONFIG_MQ_IOSCHED_DEADLINE=y
CONFIG_MQ_IOSCHED_KYBER=y
CONFIG_IOSCHED_BFQ=y
CONFIG_BFQ_GROUP_IOSCHED=y
CONFIG_NET_SCHED=y
CONFIG_DRM_SCHED_KUNIT_TEST=m
CONFIG_DRM_SCHED=m
CONFIG_DRM_XE_ENABLE_SCHEDTIMEOUT_LIMIT=y
CONFIG_USB_EHCI_TT_NEWSCHED=y
CONFIG_SCHED_STACK_END_CHECK=y
CONFIG_SCHED_INFO=y
CONFIG_SCHEDSTATS=y
CONFIG_SCHED_TRACER=y
CONFIG_RV_MON_SCHED=y

pingtoo · Post by **pingtoo** » Thu Feb 12, 2026 6:18 pm

The code is failed at

Code: Select all

1  int run_daemon(int argc, char *argv[])
2  {
3  	struct sched_param sp;
4  	ipcfd = ipc_create_server();
5  
6  	if (ipcfd < 0)
7  		die("failed to create %s (another instance already running?)", SOCKET_PATH);
8  
9  	vkbd = vkbd_init(VKBD_NAME);
10  
11  	setvbuf(stdout, NULL, _IOLBF, 0);
12  	setvbuf(stderr, NULL, _IOLBF, 0);
13  
14  	if (sched_getparam(0, &sp)) {
15  		perror("sched_getparam");
16  		exit(-1);
17  	}
18  
19  	sp.sched_priority = 49;
20  	if (sched_setscheduler(0, SCHED_FIFO, &sp)) {
21  		perror("sched_setscheduler");
22  		exit(-1);
23  	}
24  
25  	if (mlockall(MCL_CURRENT | MCL_FUTURE)) {
26  		perror("mlockall");
27  		exit(-1);
28  	}
29  
30  	evloop_add_fd(ipcfd);
31  
32  	reload();
33  
34  	atexit(cleanup);
35  
36  	keyd_log("Starting keyd "VERSION"\n");
37  	evloop(event_handler);
38  
39  	return 0;
40  }

line# 20.

It is possible the process missing the capability "CAP_SYS_NICE" or possible the Real-Time (RT) budget is not allocated correctly. check

Code: Select all

cat proc/sys/kernel/sched_rt_runtime_us

if it is "0" then it is not allowed. most likely should change it to "-1"

Section_8 · Post by **Section_8** » Fri Feb 13, 2026 12:10 am

Thank you everyone.

@pingtoo - I have

Code: Select all

officepc ~ # cat /proc/sys/kernel/sched_rt_runtime_us
950000

which seems to be the default. If I set /proc/sys/kernel/sched_rt_runtime_us to -1, keyd starts successfully, so that looks like a fix. However, when I boot gentoo-kernel-bin, it also has /proc/sys/kernel/sched_rt_runtime_us set to 950000, but keyd runs there so something else is going on.

After I posted this, I looked into my portage logs, and saw that keyd was updated from 2.5.0 to 2.6.0 on Feb 5, so that was probably when this happened. Some other overlays, such as the calculate overlay, still have keyd ebuilds at 2.5.0, so if I backlevel keyd to 2.5.0 using the calculate overlay, it runs on my gentoo-sources kernel. I think tomorrow I will ask about this upstream.

pingtoo · Post by **pingtoo** » Fri Feb 13, 2026 12:51 am

Section_8 wrote:Thank you everyone.

@pingtoo - I have
Code: Select all
officepc ~ # cat /proc/sys/kernel/sched_rt_runtime_us
950000
which seems to be the default. If I set /proc/sys/kernel/sched_rt_runtime_us to -1, keyd starts successfully, so that looks like a fix. However, when I boot gentoo-kernel-bin, it also has /proc/sys/kernel/sched_rt_runtime_us set to 950000, but keyd runs there so something else is going on.

After I posted this, I looked into my portage logs, and saw that keyd was updated from 2.5.0 to 2.6.0 on Feb 5, so that was probably when this happened. Some other overlays, such as the calculate overlay, still have keyd ebuilds at 2.5.0, so if I backlevel keyd to 2.5.0 using the calculate overlay, it runs on my gentoo-sources kernel. I think tomorrow I will ask about this upstream.

When the sched_rt_runtime_us is '>0' there are some kind of cgroup thingy need to setup. But I did not drill too deep to see what it is.

Section_8 · Post by **Section_8** » Fri Feb 13, 2026 12:55 pm

@pietinger, @pingtoo,
I took a closer look at my SCHED .config settings vs the dist-kernel settings, and it was CONFIG_RT_GROUP_SCHED that caused this. I had it set to Y (no idea why). Setting it to N fixes this without having to change sched_rt_runtime_us.

Post by **pietinger** » Fri Feb 13, 2026 5:41 pm

Section_8 wrote:@pietinger, @pingtoo,
I took a closer look at my SCHED .config settings vs the dist-kernel settings, and it was CONFIG_RT_GROUP_SCHED that caused this. I had it set to Y (no idea why). Setting it to N fixes this without having to change sched_rt_runtime_us.

I probably misunderstood @pingtoo when he asked about CONFIG_RT_GROUP_SCHED. I thought he wanted to see it enabled, which is why I posted the dist-kernel-config. So he was absolutely right to ask about it.

pingtoo · Post by **pingtoo** » Fri Feb 13, 2026 7:03 pm

pietinger wrote:
Section_8 wrote:@pietinger, @pingtoo,
I took a closer look at my SCHED .config settings vs the dist-kernel settings, and it was CONFIG_RT_GROUP_SCHED that caused this. I had it set to Y (no idea why). Setting it to N fixes this without having to change sched_rt_runtime_us.
I probably misunderstood @pingtoo when he asked about CONFIG_RT_GROUP_SCHED. I thought he wanted to see it enabled, which is why I posted the dist-kernel-config. So he was absolutely right to ask about it.

To be honest, I don't remember why I asked

Post by **pietinger** » Fri Feb 13, 2026 7:36 pm

pingtoo wrote:To be honest, I don't remember why I asked

Section_8 · Post by **Section_8** » Sat Feb 14, 2026 2:01 pm

pietinger wrote: I probably misunderstood @pingtoo when he asked about CONFIG_RT_GROUP_SCHED. I thought he wanted to see it enabled, which is why I posted the dist-kernel-config. So he was absolutely right to ask about it.

I think this is what I assumed also. I am now trying to "audit" my .config. I am looking at the output of diffconfig my .config vs. dist-kernel .config and taking a closer look at anything that looks significant.