I suspect there is a single bug here, but the behaviour differs. This
and another IPv6 related new bug held me up for several weeks, so I've
spent a lot of time looking at this.
I initially also thought it was related to treatment of comments .
However after quite a lot of testing and code inspection, it appears the
root cause is
sysctl(8) uses write(2)
systemd variant uses some form of stream IO (e.f prinntf) **
** so when a write(2) of a 10 byte buffer returns "1" (byte sent) ,
systemd keeps calling , until all 10 bytes are consumed. sysctl(8) just
stops at 1 byte
*** that said I've seen write(2) also send many bytes ... so , a bit
more complicated.
The interaction is then how the kernel level code accepts the IO for
this particular /proc variable , it accepts just 1 byte (and seems to
only differentiate "1" or not "1" ..so "6" acts like "0")
for other /proc settings the kernel side obviously behaves differently ,
since for example:
cat /proc/sys/kernel/version
#111-Ubuntu SMP PREEMPT_DYNAMIC Sat Apr 11 23:16:02 UTC 2026
Lots of bytes, including a '#' :-)
(BTW, from a different system, just a for instance)
The line in sysctl.c is:
} else {
if (0 < fprintf(fp, "%s\n", value))
rc = EXIT_SUCCESS;
Which looks like regular printf() but that "fp" comes, not from
fopen(3) but from:
if ((fp = fprocopen(path, "w")) == NULL) {
...
Then, via a long tortuous route , ends up at close() doing: (this is
from memory now, it's a while since I traced it)
if (cookie->final) {
len = write(cookie->fd, cookie->buf, cookie->offset);
There is a whole bunch of special cases "delimiter characters" etc and
a liberal scattering of gotos :-)
On 09/05/2026 14:35, Debian Bug Tracking System wrote:
Thank you for the additional information you have supplied regarding
this Bug report.
This is an automatically generated reply to let you know your message
has been received.
Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.
Your message has been sent to the package maintainer(s):
[email protected]
If you wish to submit further information on this problem, please
send it to [email protected].
Please do not send mail to [email protected] unless you wish
to report a problem with the Bug-tracking system.
