Re-deprecating sysctl()

By Jonathan Corbet
August 29, 2007

The sysctl() system call allows a suitably-privileged application to tweak various kernel parameters. It is a useful feature which, as it happens, is almost never used. The reason for that is the existence of the /proc/sys virtual directory hierarchy which exports the same functionality in a form which is much easier to use. Callers of sysctl() have been encouraged to use /proc/sys instead for a long time and the addition of new parameters to sysctl() is considered to be against the rules. One year ago, sysctl() was removed from the 2.6.19-rc kernels, only to be restored before the final release.

sysctl() is part of the user-space ABI; it is supposed to continue working forever. That is why the attempt to remove it was ultimately rolled back. So it may be surprising to some to see a new removal attempt by Eric Biederman. His latest patch adds a new deprecation warning and an entry in the feature removal schedule putting the end of sysctl() in September, 2010. Says Eric:

After adding checking to register_sysctl_table and finding a whole new set of bugs. Missed by countless code reviews and testers I have finally lost patience with the binary sysctl interface.

The binary sysctl interface has been sort of deprecated for years and finding a user space program that uses the syscall is more difficult then finding a needle in a haystack. Problems continue to crop up, with the in kernel implementation. So since supporting something that no one uses is silly, deprecate sys_sysctl with a sufficient grace period and notice that the handful of user space applications that care can be fixed or replaced.

Eric's claim is that this interface is so little-used that it is visibly rotting. There is sufficiently little common code between the sysctl() and /proc/sys implementations that it is easy for the two to diverge. In the long term, he says, the kernel community will do a better job of not breaking applications by getting rid of sysctl() in favor of the interface which is actually used and maintained.

The new patch has, predictably, drawn opposition from developers who do not want to see the user-space ABI broken in this way. Alan Cox has also suggested that the deprecation warning approach will not be successful in getting the few remaining users to switch to /proc/sys:

The whole "whine a bit" process simply doesn't work when you are trying to persuade people to move in a non-hobbyist context. They don't want to move, the message is simply an annoyance, their upstream huge package vendor won't change just to deal with it and they'll class it as a regression from previous releases, an incompatibility and file bugs until it goes away.

Andrew Morton, instead, is not opposed to the patch:

I think it's worth a try. It might take two, three or five years, who knows? If it turns out to be impractical then we we can just change our minds later, no big loss.

While there is little disagreement with the policy that the user-space ABI should never break, it does seem that there is room for discussion on how that goal might best be met. Unused code has always had a tendency to break accidentally, and sysctl() looks to be very close to being entirely unused. One could, presumably, address this problem with some sort of regression test suite - something the kernel could use more of in general. But the maintenance of interfaces which of almost entirely historical interest is not really helpful to Linux users. So, perhaps, there needs to be a way to remove system calls which have fallen into disuse for a long-enough period. Should this patch go through, we shall see whether three years is sufficient warning for such a change or not.

Index entries for this article
Kernel	Development model/User-space ABI
Kernel	Sysctl

Re-deprecating sysctl()

Posted Aug 30, 2007 1:07 UTC (Thu) by JoeBuck (subscriber, #2330) [Link] (1 responses)

What if sysctl() were replaced by a library that performed the same functions by accessing the /proc/sys filesystem? Then the rotted code could be removed from the kernel but clients would continue to function. As long as the intent is to provide similar capabilities from /proc/sys, the code to do the translation from one to the other could live in userspace. After all, apps don't invoke the kernel directly, they go through glibc to do a sysctl().

Re-deprecating sysctl()

Posted Aug 30, 2007 10:09 UTC (Thu) by nix (subscriber, #2304) [Link]

Well, glibc is one of the (very few) users, and although it does fall back to /proc/sys where needed, that's going to be both slower (more syscalls) and won't work in chroots or other environments where /proc may not be mounted.

And it's generally considered bad to require a new glibc with a new kernel...

Re-deprecating sysctl()

Posted Aug 30, 2007 9:41 UTC (Thu) by addw (guest, #1771) [Link] (6 responses)

<blockquote>we shall see whether three years is sufficient warning for such a change or not.</blockquote><p>
Probably not. Someone putting in a new machine today will, reasonably, expect it to work for the lifetime of the hardware - say 7 years.
<p>
What ought to be done is for the kernel to log that sysctl() has been used and by what program. This will allow the identification of programs that will break when sysctl() is eventually killed.

Re-deprecating sysctl()

Posted Aug 30, 2007 10:10 UTC (Thu) by nix (subscriber, #2304) [Link] (2 responses)

Every program will emit this log message: glibc calls sysctl() at startup.

Re-deprecating sysctl()

Posted Aug 30, 2007 15:45 UTC (Thu) by jzbiciak (guest, #5246) [Link] (1 responses)

Indeed, from an strace of ls:

    _sysctl({{CTL_KERN, KERN_VERSION}, 2, 0xbfffe41c, 31, (nil), 0}) = 0

Seems like it'd be easy to filter out *that* specific use (getting the kernel version number), and report all the other uses. This also argues that the kernel will probably need to support this specific sysctl even if it deprecates and ultimately removes other sysctl support. After all, we have statically linked binaries out there.

Re-deprecating sysctl()

Posted Aug 30, 2007 20:01 UTC (Thu) by ebiederm (subscriber, #35028) [Link]

And that is what I implemented in my patch.

A printk that logs when you use it and with which program and that
filters out the glibc usage.

Not that the glibc usage is a big deal because it is just a check for
non-SMP to optimize pthreads so any value gives you correctly running
code.

Eric

Re-deprecating sysctl()

Posted Aug 30, 2007 17:49 UTC (Thu) by jwb (guest, #15467) [Link] (2 responses)

Changes in the upstream kernel do not break existing installations. If you don't want your software to change, don't install a new kernel.

Re-deprecating sysctl()

Posted Aug 30, 2007 18:14 UTC (Thu) by bronson (subscriber, #4806) [Link] (1 responses)

In other words, it's a Linux 3.0 change?

Re-deprecating sysctl()

Posted Aug 30, 2007 23:47 UTC (Thu) by nix (subscriber, #2304) [Link]

Current Linux still runs a lot of statically linked programs dating from
1992, modulo occasional a.out-related breakage. I don't see why that
should ever change (perhaps because a.out support finally gets dumped: I'm
not sure how useful it is to be able to run programs which predate Windows
3.1...)

Re-deprecating sysctl()

Posted Aug 30, 2007 10:09 UTC (Thu) by jengelh (subscriber, #33263) [Link] (6 responses)

People running unrecompilable proprietary software which will not be updated by the vendor are likely to be running some server distribution and stay with the kernel that shipped. IMHO, it should be removed right now.

Re-deprecating sysctl()

Posted Aug 30, 2007 14:25 UTC (Thu) by mrshiny (subscriber, #4266) [Link] (5 responses)

I would disagree. Having worked in a computer sales/support/repair role, I can say that many times I had a headache of trying to make an old application run on a new platform. Usually there was no chance of upgrading the application because of a variety of reasons, including budgetary or regulatory reasons. Sometimes the vendor still supported the application but didn't support it on a modern OS or hardware.

For one example: many DOS programs were bitten by a bug where they crashed when run on a Pentium III with a 100Mhz bus. This was caused by some flaw in the time logic in some standard library (a Pascal library of some sort, IIRC). There was actually a program floating around on the internet that could patch these programs and make them work properly, but in many cases the vendors themselves did not have a solution for the clients.

Anyway, my point is that hardware failure can necessitate hardware upgrades which can necessitate OS upgrades which can lead to sysctl() not being present if you're upgrading Linux. I don't think it's an unlikely scenario.

Re-deprecating sysctl()

Posted Aug 30, 2007 14:47 UTC (Thu) by jengelh (subscriber, #33263) [Link] (2 responses)

That is a standpoint I can accept. But then again, vendors don't have their software certified or (officially) tested for this new kernel _at all_ (example: VMware). When you call their hotline, they will just tell you that. And then you are stuck - either buy hardware that runs on the usual kernel, or do anything to get the old software to run on a new kernel, possibly modifying the application in ways that invalidate the service contracts. And this is the point I really was aiming at. When enough people get into that awkward situation and request support for newer kernels, the vendor will (if we look at this on a purely mathematical and logical basis...) revalidate their software for newer kernels (...otherwise the customers will be running away). The sooner the better.

Bet what will happen. I bet that if sysctl() is going away in September 2010, then the earliest userspace software upgrade wrt. sysctl() we will see will be after {date of next non-rc release after sysctl removal}. What I believe is that even though we shout "sysctl() is going away in 3 years!", noone will be listening until it actually happened. And when it is about to go away, one side of the kernel developer group ("Janitors") will try to remove it while the other side ("Home") whines about retaining it.

Just look at the RAW character device driver. There have been futile attempts at other things too.

Re-deprecating sysctl()

Posted Aug 31, 2007 1:29 UTC (Fri) by mrshiny (subscriber, #4266) [Link] (1 responses)

Well, don't get me wrong, I think a certain amount of backwards compatibility can be sacrificed in the name of progress, especially if (as is believed) nobody is actually using the sysctl interface anyway. Anyway it may be possible to write a patch for certain programs if those programs can't be modified; basically a stripped down sysctl could be made to emulate the behaviour of an unfixable app. But I can pretty much guarantee that SOMEONE will suffer due to the loss of this function. Some app somewhere that can't or won't be fixed will stop working and some business will lose money while a solution is investigated.

Re-deprecating sysctl()

Posted Aug 31, 2007 8:03 UTC (Fri) by jengelh (subscriber, #33263) [Link]

Constructive destruction ;-)

Re-deprecating sysctl()

Posted Sep 1, 2007 0:38 UTC (Sat) by landley (guest, #6789) [Link] (1 responses)

> Anyway, my point is that hardware failure can necessitate hardware
> upgrades which can necessitate OS upgrades which can lead to sysctl()
> not being present if you're upgrading Linux. I don't think it's an
> unlikely scenario.

And if the hardware that failed was at least 3 years old you can run the
old os image with the old kernel under qemu on current hardware and not
lose any speed, and do whatever funky network bridging or VNC you need to
access the old app.

Re-deprecating sysctl()

Posted Sep 1, 2007 12:55 UTC (Sat) by mrshiny (subscriber, #4266) [Link]

As long as you don't require custom hardware that isn't accessible to qemu.

I like Alan's idea

Posted Sep 6, 2007 7:44 UTC (Thu) by anandsr21 (guest, #28562) [Link]

Just keep on trimming features from sysctl and sometime in the future there will be nothing left, or at least it will have very little, and will not be a support nightmare. Later when there are very few things left put them into glibc and get rid of it totally.