On Wed, Sep 23, 2026 at 08:49:04 -0400, Frank McCormick wrote:
> Updated my Sid installation this morning and I was struck by a warning
> partway
>
> through the job.
>
> Setting up systemd (262-1)…
> Unrecognized signal name "SIGRTMIN+25" at /usr/bin/deb-systemd-invoke line
> 179.
>
> Should I be concerned or is this a harmless warning?
Well, here's what my (trixie) deb-systemd-invoke script contains:
if ($action eq "daemon-reload") {
$signal = 'SIGHUP';
} else {
$signal = 'SIGRTMIN+25';
}
if ($is_system) {
system('kill', '-s', $signal, '1');
} else {
system('systemctl', '--quiet', 'kill', '--kill-whom=main', '--signal',
$signal, 'user@*.service');
}
The line in question is the first system() call, with kill -s.
And these are the valid signals according to Trixie bash's "kill -l":
hobbit:~$ kill -l
1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL 5) SIGTRAP
6) SIGABRT 7) SIGBUS 8) SIGFPE 9) SIGKILL 10) SIGUSR1
11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM 15) SIGTERM
16) SIGSTKFLT 17) SIGCHLD 18) SIGCONT 19) SIGSTOP 20) SIGTSTP
21) SIGTTIN 22) SIGTTOU 23) SIGURG 24) SIGXCPU 25) SIGXFSZ
26) SIGVTALRM 27) SIGPROF 28) SIGWINCH 29) SIGIO 30) SIGPWR
31) SIGSYS 34) SIGRTMIN 35) SIGRTMIN+1 36) SIGRTMIN+2 37) SIGRTMIN+3
38) SIGRTMIN+4 39) SIGRTMIN+5 40) SIGRTMIN+6 41) SIGRTMIN+7 42) SIGRTMIN+8
43) SIGRTMIN+9 44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13
48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13 52) SIGRTMAX-12
53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9 56) SIGRTMAX-8 57) SIGRTMAX-7
58) SIGRTMAX-6 59) SIGRTMAX-5 60) SIGRTMAX-4 61) SIGRTMAX-3 62) SIGRTMAX-2
63) SIGRTMAX-1 64) SIGRTMAX
And Trixie's /usr/bin/kill -L:
hobbit:~$ /usr/bin/kill -L
1 HUP 2 INT 3 QUIT 4 ILL 5 TRAP 6 ABRT 7 BUS
8 FPE 9 KILL 10 USR1 11 SEGV 12 USR2 13 PIPE 14 ALRM
15 TERM 16 STKFLT 17 CHLD 18 CONT 19 STOP 20 TSTP 21 TTIN
22 TTOU 23 URG 24 XCPU 25 XFSZ 26 VTALRM 27 PROF 28 WINCH
29 POLL 30 PWR 31 SYS
SIGRTMIN+25 is not in either list, but in the Trixie version of procps's
/usr/bin/kill, SIGRTMIN+25 is accepted as an operand of the -s option.
hobbit:~$ kill -s RTMIN+15 62351
hobbit:~$ kill -s RTMIN+25 62510
hobbit:~$ kill -s SIGRTMIN+25 63179
hobbit:~$
(Those PIDS all belonged to "sleep 1000" commands running in another
terminal, so that I had valid processes to signal.)
Presumably, the sid version of procps has changed kill -s so that it no
longer accepts signal names which are out of range, which means, in
your case, PID 1 did not receive the signal the script was trying to
send to it.
The man page for systemd(1) says:
SIGRTMIN+25
Upon receiving this signal the systemd manager will reexecute
itself. This is mostly equivalent to systemctl daemon-reexec except
that it will be done asynchronously.
The systemd system manager treats this signal the same way as
SIGTERM.
Added in version 250.
At the very minimum, this deserves a bug report, I would say. It's not
clear to me why the systemd developers think "SIGRTMIN+25" is a valid
signal name. It's also not clear to me why they're calling an external
kill process instead of using perl's builtin kill function. Either
way, my opinion is that this bug is in systemd, not in procps.
If you haven't rebooted yet, you might want to send SIGTERM to PID 1,
or just reboot to be sure.
