Enterprise Unix Roundup: A Taste of Linux Kernel 2.6

There are some who judge the Linux kernel in the same way they consider wine. While the 2.0 and 2.2 series are remembered as good vintages, the 2.4 series was a troubled one that required a lot of point releases before people got around to trusting it much. It also had the unfortunate distinction of undergoing a major overhaul to a critical subsystem (the virtual memory manager) midway through its life. A feature freeze in the Linux kernel has some developers concerned, but it's likely the hobbyist/enterprise partnership that drives Linux will lay those fears to rest. Plus: Sun offers free downloads of Solaris x86 ... and tips on the Unix slay command.

So with a new kernel on its way (version 2.6), there's a natural curiosity about how this particular vintage is going to shape up: smooth and unsurprising like 2.2, or maybe a little tart, like 2.4.

We won't claim to know, because outside skimming the release notes for each development release we don't much play around with the Linux kernel's development versions (the odd-numbered ones, such as the 2.5 series which just gave way to the 2.6-testing versions). There's no real future in it for the sorts of things we're doing day-to-day around the Roundup Ranch.

When Linux kernel 2.6.0 is released, though, we have a reliable testbed machine we'll try it out on, and we'll probably spend several months following releases closely, monitoring the usual mailing lists, and listening for what others are finding. We suspect there are a lot of Linux users like us, especially in the enterprise space, who won't want to bother with release chasing, and they'll want their favorite distributor to go through a round of patching and packaging.

There will be, however, a lot of folks who will start pressing the new kernel into service almost immediately. We know of one eager Web master who considered his adoption Linux 2.4.0 the day it was released as a point of pride. We thought he was crazy. But out of those many people like him, the real strength of Linux' design methodology will come to the fore: There will be a lot of folks hammering away at the "final" product, paving the way for refinements over its lifespan that will make the later point releases as smooth as other classic kernel vintages.

It's an interesting point of contact between the hobbyist/"consumer" world and the enterprise world: By the time you get around to adopting the new kernel for your production servers, a lot of folks with considerably less at stake than a data center or financial application will have caught much that would have made your life difficult. While there are some heroic figures in the Linux development community, there are also a lot of folks tucked away in the Red Hats and SUSEs who will work on the current series with an eye to making it useful for the products their bosses are trying to sell.

That's why the minor tempest over Linux 2.4 series maintainer Marcelo Tosatti's decision to freeze new features in order to encourage developer attention to the 2.6 series seems ill-considered. The argument goes that the best and brightest of the Linux developer community will move on to the 2.7 development series right away, spending no time with the 2.6 series out of a desire to chase down the newer, more interesting challenges.

While it's probably true that the superstars will move on, the quiet pros will still be plugging away, adding refinements and listening to the massive testing community out there. It's part of the appeal of the Linux development process now that the project has become so intertwined in both the grassroots developer community that spawned it, and the enterprise community that has come to depend on it.

We're predicting the same smooth finish for Linux 2.6 that we got with the versions that came before it.

In the News

  • Sun has reopened Solaris x86 to free downloads under its Free Solaris Binary License Program, returning to the status quo that prevailed before it first tried to abandon the OS earlier this year.
  • We weren't sure about Sun's wisdom when the company decided to name its former "Mad Hatter" the Java Desktop System. Now that we've read about Sun's pending deal with WalMart to put JDS-powered systems on the shelves, and come across analysts describing the product as "Java-based" in response to the deal, we're sure our instinct was correct. Sun's eagerness to push Linux to the background by covering the product with the Java brand just means marketplace confusion in exchange for a point of pride.
  • SCO suffered a setback when the judge in its case against IBM told the company to provide evidence IBM says SCO has been witholding. SCO preferred to spin the matter as a question of the judge asking SCO's help in getting things rolling. Looks more like the judge ordered an abrupt end to SCO's prolonged fishing trip. The company also fell victim to a denial of service attack on Wednesday, which it was quick to blame on "someone from the Linux community." For its part, some in the Linux community are wondering if SCO was even really under attack.
  • SGI's xfs journaling file system has ended up in the 2.4 series of the Linux kernel despite earlier indications it wouldn't be included in the core distribution until the 2.6 series. The primary issue is less the filesystem's ability to work with the Linux kernel, which it has for some time, but whether an extra download of the filesystem's source from SGI would be required to patch the Linux kernel and use it.

Security Roundup:

Just after we went to press last week, a number of distributors released updates of rsync (which our readers may remember from a previous Tip of the Trade. The bug this update patched was serious enough to be involved in a spate of compromises of high-profile Linux projects, including the Gentoo distribution and the Savannah project's servers. If you're running rsync in server mode, this one warrants a look.

Tips of the Trade:

The Roundup Ranch is home to a small artists colony of a server, where some creative folks without a lot of bandwidth or terms of service with their ISP that will allow them to run services. We enjoy providing the service because it keeps us in the "serving the end user" game that writing about this stuff keeps us from more than we might like, and it gives us a chance to see what cutting-edge types are playing with. We provide a lot of room for experimentation, provide whatever tools our users need, and keep an open mind. But when a recent project got out of control, we were glad to have one of those weapons of last resort that sysadmins depend on when all else fails: the merciless slay.

What's slay? Think of it as kill's thermonuclear cousin.

The situation was this: Our consumer-grade DSL connection went down for service at some point in the evening. A collection of clever programs one of our users wrote to collect newsfeeds and republish them on his site continued to run, and run, and run. Even though there was no Net to connect to, they ran every few minutes, creating a new process, waiting for a response from a server they couldn't connect to. By the time we got up the next morning and looked in on our server, there were so many running processes that we couldn't run many commands without getting errors because the total allowable number of open files was maxing out. We were able to run a quick ps ax, which told us that the processes were also running with many different names, which made killall a tough proposition. We didn't want to have to use it for every program running, because there were at least a dozen different program names.

With the server slowly collapsing under the weight of all these programs, though, we had to do something. So we unleashed slay, which works with a single argument: the login name of the user whose processes you want to kill. You can add which signal to use, as well, so for extra pesky processes you can slay -9 username.

The tricky thing about slay is the differences between commands of the same name on varying systems. In Linux and BSD variants, slay performs as we described it. Under QNX, it works more like killall, working by processname instead of username, and it doesn't turn up at all in a few other Unixes. So before you unleash it on a user whose processes are running amok, make sure to check the man page and see just what it does.

More ServerWatch News

This article was originally published on Dec 12, 2003
Page 1 of 1

Thanks for your registration, follow us on our social networks to keep up-to-date