There's real reasons for Linux to replace ifconfig, netstat, et al

May 25, 2018

One of the ongoing system administration controversies in Linux is that there is an ongoing effort to obsolete the old, cross-Unix standard network administration and diagnosis commands of ifconfig, netstat and the like and replace them with fresh new Linux specific things like ss and the ip suite. Old sysadmins are generally grumpy about this; they consider it yet another sign of Linux's 'not invented here' attitude that sees Linux breaking from well-established Unix norms to go its own way. Although I'm an old sysadmin myself, I don't have this reaction. Instead, I think that it might be both sensible and honest for Linux to go off in this direction. There are two reasons for this, one ostensible and one subtle.

The ostensible surface issue is that the current code for netstat, ifconfig, and so on operates in an inefficient way. Per various people, netstat et al operate by reading various files in /proc, and doing this is not the most efficient thing in the world (either on the kernel side or on netstat's side). You won't notice this on a small system, but apparently there are real impacts on large ones. Modern commands like ss and ip use Linux's netlink sockets, which are much more efficient. In theory netstat, ifconfig, and company could be rewritten to use netlink too; in practice this doesn't seem to have happened and there may be political issues involving different groups of developers with different opinions on which way to go.

(Netstat and ifconfig are part of net-tools, while ss and ip are part of iproute2.)

However, the deeper issue is the interface that netstat, ifconfig, and company present to users. In practice, these commands are caught between two masters. On the one hand, the information the tools present and the questions they let us ask are deeply intertwined with how the kernel itself does networking, and in general the tools are very much supposed to report the kernel's reality. On the other hand, the users expect netstat, ifconfig and so on to have their traditional interface (in terms of output, command line arguments, and so on); any number of scripts and tools fish things out of ifconfig output, for example. As the Linux kernel has changed how it does networking, this has presented things like ifconfig with a deep conflict; their traditional output is no longer necessarily an accurate representation of reality.

For instance, here is ifconfig output for a network interface on one of my machines:

 ; ifconfig -a
 [...]
 em0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
    inet 128.100.3.XX  netmask 255.255.255.0  broadcast 128.100.3.255
    inet6 fe80::6245:cbff:fea0:e8dd  prefixlen 64  scopeid 0x20<link>
    ether 60:45:cb:a0:e8:dd  txqueuelen 1000  (Ethernet)
 [...]

There are no other 'em0:...' devices reported by ifconfig, which is unfortunate because this output from ifconfig is not really an accurate picture of reality:

; ip -4 addr show em0
[...]
  inet 128.100.3.XX/24 brd 128.100.3.255 scope global em0
    valid_lft forever preferred_lft forever
  inet 128.100.3.YY/24 brd 128.100.3.255 scope global secondary em0
    valid_lft forever preferred_lft forever

This interface has an IP alias, set up through systemd's networkd. Perhaps there once was a day when all IP aliases on Linux had to be set up through additional alias interfaces, which ifconfig would show, but these days each interface can have multiple IPs and directly setting them this way is the modern approach.

This issue presents programs like ifconfig with an unappealing choice. They can maintain their traditional output, which is now sometimes a lie but which keeps people's scripts working, or they can change the output to better match reality and probably break some scripts. It's likely to be the case that the more they change their output (and arguments and so on) to match the kernel's current reality, the more they will break scripts and tools built on top of them. And some people will argue that those scripts and tools that would break are already broken, just differently; if you're parsing ifconfig output on my machine to generate a list of all of the local IP addresses, you're already wrong.

(If you try to keep the current interface while lying as little as possible, you wind up having arguments about what to lie about and how. If you can only list one IPv4 address per interface in ifconfig, how do you decide which one?)

In a sense, deprecating programs like ifconfig and netstat that have wound up with interfaces that are inaccurate but hard to change is the honest approach. Their interfaces can't be fixed without significant amounts of pain and they still work okay for many systems, so just let them be while encouraging people to switch to other tools that can be more honest.

(This elaborates on an old tweet of mine.)

PS: I believe that the kernel interfaces that ifconfig and so on currently use to get this information are bound by backwards compatibility issues themselves, so getting ifconfig to even know that it was being inaccurate here would probably take code changes.


Comments on this page:

From 90.131.35.5 at 2018-05-25 04:43:25:

if you're parsing ifconfig output on my machine to generate a list of all of the local IP addresses, you're already wrong.

Especially after ifconfig's output changed in the last release (and presumably broke a whole lot of scripts), and especially when ip addr can output JSON...

Thank you for writing this. I have never understood the criticism of iproute2; after all, it was not like BSD ifconfig worked the same as Linux ifconfig for all but the simplest things. Same for netstat, ss is a big improvement there IMO.

By Vincent Bernat at 2018-05-25 08:17:16:

Also, net-tools has been unmaintained for years until recently. In BSD, the same team maintains the userspace and the kernel and keeps them in sync. That's not the case for Linux. There was no other choice for Linux to build its own tools to support the new features.

By KyleG at 2018-05-25 12:02:50:

So systemd fails to register an interface alias correctly in the "proc" filesystem space, and because of that we should rewrite tried-n-true tools? I hate wasting time re-arranging furniture. Rewriting ifconfig because systemd is shit feels like a lot of wasted time and unintended consequences to me.

But, Poettering is not likely going to fix his shit, so RedHat and Debian will have no choice but to waste their time and deal with the unintended consequences.

KyleG

By dozzie at 2018-05-25 14:06:38:

So systemd fails to register an interface alias correctly in the "proc" filesystem space, and because of that we should rewrite tried-n-true tools?

No. First, iproute2 and setting or not a label for an address is something present far longer than systemd has been around. Second, it's the other way around: a label got developed specifically as a workaround for ifconfig.

ifconfig (and route) is out of sync with what you can do with networking for more than a decade.

By Grumpy Dave. at 2018-05-25 18:54:09:

I think the real reason we don't want to abandon those old tools is shell scripts. You have stuff working. Someone says "Oh you go to go deep into the guts and rip something out and rewrite it with a different command because it is too slow"

It is a shell script it is always slow! It is a shell script from 10 years ago and you want me to modify it? Shell is like perl it is a write once language.

If you think I am exaggerating look how long it took people to stop using init scripts.

By jmz at 2018-05-26 21:24:59:

i am no programmer at all but linux newbie. why not call linux ss et al ifconfog et al ? problem solved ?

By Greg A. Woods at 2018-05-26 21:54:32:

It's always enlightening, though often frightening, and usually frustrating, to hear of the trials and tribulations of the Linux world. I'm ever so glad my encounters with Linux are limited mostly to its POSIX API and the odd shell prompt for running tests on servers I don't have to manage or maintain.

It's too bad POSIX and X/Open never really grew a proper minimum standard for systems administration tools, files, and interfaces.

I wonder when the Linux world will give up entirely on POSIX for even the basics. Maybe that's why so many Linux programers continue to maintain soooo many pointless configure scripts and unnecessary "portability" hacks in their code -- they know that one day those scripts and hacks will be necessary again.

By Nils H at 2018-05-27 11:31:41:

The biggest problem I have is that new commands are introduced with new options that aren't matching the old options.

If the new solution uses the old names and options with added options then I really wouldn't care much since the command that is ingrained in my spine still is there. Creating a new command is a huge time waster because then the commands differ between systems. It's bad enough with the "ps -ef" and "ps -aux" variation that do basically the same thing but on different systems.

Parsing the output is as I see it something that is a last resort option anyway and anyone doing that will have to adapt in the next major OS release anyway.

By gnu_lorien at 2018-05-27 13:26:00:

I thought ss was kinda bunk until two months ago when it saved me in a production environment. netstat can't accurately tell you the buffer state and buffer size for a socket. ss shows you this organized by input and output side by default when looking at TCP sockets. I never would have noticed the curious fact that certain connections had a number of bytes waiting to be read that perfectly matched the size of our startup packet. Suddenly this stalled communication bug was obvious: One side wasn't reading the buffer when the connection was initiated in a certain way.

By J Osborne at 2018-06-18 12:54:56:

"i am no programmer at all but linux newbie. why not call linux ss et al ifconfog et al ? problem solved ?"

That sort of solves the problem if the thing running ifconfig or netstat is a human. It frequently is not.

If another program (normally a shell script) runs ifconfig because it wants to figure out "all the IP addresses" then not only does it require a program named 'ifconfig' to exist, but for it to also have the exact same output it expects. A human can (with varying levels of irritation) handle deviation from what they have seen in the past, and even what some written instructions may say, but a program just isn't that flexible.

The point of this article is that not only does ss/ip have different output formats, that sometimes the old output format of netstat and ifconfig also can't really match the reality of how interfaces and such can be configured on a Linux system.

Also even if people can respond better to change then most programs, you still suffer from the "who MOVED my cheese!" syndrome.

Are you actually using ifconfig correctly? On BSD, if you simply use `ifconfig` or `ifconfig -a`, then indeed the secondary alias addresses for a given interface will not be shown. But doing an `ifconfig em0`, with the explicit name of the interface that you're after, does reveal every address for the given interface.

Is Linux different? And, even if not, this is still a very superficial reason for replacing ifconfig.

By cks at 2018-06-18 19:25:45:

Linux's ifconfig is indeed different from BSD ifconfig here. The problem for it goes deeper than it just not printing out the data; it only uses an (old) kernel API, and that API specifically only returns a single address. The kernel literally can't let ifconfig know that the interface has multiple IP addresses; it has to pick one (the primary one), and so ifconfig only tells you about that one.

(If you want to see the saugage being made, ifconfig uses SIOCGIFADDR, which you can read about in netdevice(7).)

Written on 25 May 2018.
« Registering for things on the Internet is dangerous these days
Some notes on Go's runtime.KeepAlive() function »

Page tools: View Source, View Normal, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri May 25 01:31:08 2018
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.