How to use ss command instead of netstat in Linux operation and maintenance

Preface

When operating and managing Linux servers, one of the most commonly used commands is netstat. I often use this command to check which processes on the current server are listening to ports. It is mainly used to diagnose the working status of network services.

However, recently when I installed a new Ubuntu distribution, I discovered that netstat was not installed by default. I found this very strange, so after I installed it manually, I found that the man pages indicated that the netstat command had been deprecated and that it was recommended to use the ss command instead.

This program is mostly obsolete. Replacement for netstat is ss. Replacement for netstat -r is ip route. Replacement for netstat -i is ip -s link. Replacement for netstat -g is ip maddr.

netstat man pages

Usage of netstat

There are many, many parameters for netstat. I usually use a combination of them, so I can't remember why I used these parameters later:

netstat -npl

The result is this:

Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN 655/systemd-resolve
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 890/sshd
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 30790/cupsd
tcp 0 0 0.0.0.0:18025 0.0.0.0:* LISTEN 890/sshd
tcp6 0 0 :::22 :::* LISTEN 890/sshd
tcp6 0 0 ::1:631 :::* LISTEN 30790/cupsd
tcp6 0 0 :::9090 :::* LISTEN 15415/./prometheus
tcp6 0 0 :::18025 :::* LISTEN 890/sshd
udp 0 0 127.0.0.53:53 0.0.0.0:* 655/systemd-resolve
udp 0 0 0.0.0.0:631 0.0.0.0:* 30792/cups-browsed
udp 0 0 0.0.0.0:5353 0.0.0.0:* 757/avahi-daemon: r
udp 0 0 0.0.0.0:42360 0.0.0.0:* 757/avahi-daemon: r
udp6 0 0 :::58232 :::* 757/avahi-daemon: r
udp6 0 0 :::5353 :::* 757/avahi-daemon: r
Active UNIX domain sockets (only servers)
Proto RefCnt Flags Type State I-Node PID/Program name Path
unix 2 [ ACC ] STREAM LISTENING 35116 1304/gnome-session- @/tmp/.ICE-unix/1304
unix 2 [ ACC ] SEQPACKET LISTENING 1448 1/init /run/udev/control
unix 2 [ ACC ] STREAM LISTENING 34277 1270/systemd /run/user/1000/systemd/private
unix 2 [ ACC ] STREAM LISTENING 34282 1270/systemd /run/user/1000/gnupg/S.gpg-agent.ssh
unix 2 [ ACC ] STREAM LISTENING 33510 1270/systemd /run/user/1000/gnupg/S.gpg-agent
unix 2 [ ACC ] STREAM LISTENING 33511 1270/systemd /run/user/1000/pulse/native
unix 2 [ ACC ] STREAM LISTENING 33512 1270/systemd /run/user/1000/gnupg/S.gpg-agent.extra

The most commonly used command combination is this one. The results displayed have two paragraphs. The first paragraph shows the listening status of the TCP/UDP protocol, and the second paragraph shows the listening status of the socks file. The parameter n means to display the IP address in digital format, otherwise the host name or domain name will be displayed. The parameter p means to display the name of the process (sometimes it cannot be displayed). The meaning of l is to focus on the socket in the LISTENING state.

Through the above command, we can see all the open sockets in the system. If you start a network service or develop a network service to open a port, you should be able to see the port you opened through this command. If you can't see it, it means that the port was not opened correctly. You should check the reason. So this is a very useful debugging command.

Usage of ss

The above introduces the most basic usage of netstat. There are of course many other uses, but we will skip them for now. If we want to use the ss command instead of netstat, how can we achieve a similar effect?

ss-atlp

This is a parameter combination that I figured out by myself. I am not very fluent in reciting it yet, and I need to look at the documentation every time:

State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 128 127.0.0.53%lo:domain 0.0.0.0:* users:(("systemd-resolve",pid=655,fd=13))
LISTEN 0 128 0.0.0.0:ssh 0.0.0.0:* users:(("sshd",pid=890,fd=5))
LISTEN 0 5 127.0.0.1:ipp 0.0.0.0:* users:(("cupsd",pid=30790,fd=7))
LISTEN 0 128 0.0.0.0:18025 0.0.0.0:* users:(("sshd",pid=890,fd=3))
LISTEN 0 128 [::]:ssh [::]:* users:(("sshd",pid=890,fd=6))
LISTEN 0 5 [::1]:ipp [::]:* users:(("cupsd",pid=30790,fd=6))
LISTEN 0 128 *:9090 *:* users:(("prometheus",pid=15415,fd=3))
LISTEN 0 128 [::]:18025 [::]:* users:(("sshd",pid=890,fd=4))

This is the result presented by the ss command. You can see that the format is very different from netstat and is not as compact and intuitive as the netstat command. This is one of the reasons why many people criticized this order. Of course, critics of this criticism believe that people are simply clinging to a habit and are unwilling to move forward. Of course, there is something wrong with saying this. Take Charles as an example. Even though I learned the netstat command when I started working in 2010, I have been using it for nearly ten years and have never changed it. Of course, I like it very much.

Of course, there is also a reason put forward by foreigners, saying that the name of the ss command is not good. In fact, ss may mean socket statistics. After the abbreviation, it has only two letters, which is not easy to associate with, and is not as intuitive as netstat. Of course this is just my explanation, not a reason for foreigners to complain. What they complain about is that whenever ss is mentioned, they think of Hitler! Isn't it incredible? I was born in the 1980s. People of my generation have no impression of this. The key is that we mainly speak Chinese. I guess when people see ss, they will most think of ladders, and will never think of Hitler. This great Nazi had an armed force, formerly called the SS Special Mobile Unit, and later renamed the Waffen SS. Its German abbreviation is SS.

Without further ado, let me talk about a few parameters. The a parameter means to display all, the t parameter means to display the TCP protocol, l represents the LISTENING state, and p represents the process information. From the table above, we can see that the information printed by the p parameter is not as concisely organized as that of netstat. But it is more complete, showing the process name, PID and FD. But because of the double parentheses, key/value format, and quotation marks, it looks messy. Of course, we can use some commands to format it, but it is still too troublesome.

What is the reason for the replacement?

This is probably what I'm most curious about. However, I searched a lot of information online, but it was basically vague. This also makes me a little helpless.

In general, we can see that the main package is the net-tools package, which will be replaced by the iproute package. The reasons are probably: 1. This package is too old; 2. This package does not support many new kernel features (but it does not say which features), the interface is not optimized enough and difficult to use (not command line friendly); 3. ifconfig in net-tools does have many shortcomings; 4. I no longer want to maintain net-tools in the future.

Luk Claes and me, as the current maintainers of net-tools, we've been thinking about it's future. Net-tools has been a core part of Debian and any other linux based distro for many years, but it's showing its age.

It doesn't support many of the modern features of the linux kernel, the interface is far from optimal and difficult to use in automatisation, and also, it hasn't got much love in the last years.

On the other side, the iproute suite, introduced around the 2.2 kernel line, has both a much better and consistent interface, is more powerful, and is almost ten years old, so nobody would say it's untested.

Hence, our plans are to replace net-tools completely with iproute, maybe leading the route for other distributions to follow. Of course, most people and tools use and remember the venerable old interface, so the first step would be to write wrappers, trying to be compatible with net-tools.

At the same time, we believe that most packages using net-tools should be patched to use iproute instead, while others can continue using the wrappers for some time. The ifupdown package is obviously the first candidate, but it seems that a version using iproute has been available in experimental since 2007.

https://serverfault.com/questions/633087/where-is-the-statement-of-deprecation-of-ifconfig-on-linux

There is also an analysis from the principle level: the current netstat and ifconfig commands both complete their tasks by reading and writing virtual files in the /proc directory. This is fine for small business systems, but in large-scale systems, it may harm system performance. In contrast, the ss and ip commands use the netlink sockets feature of the Linux kernel. There is a fundamental difference. Although old commands can be rewritten using new principles, no one actually does so, mainly because of some political issues among different programmer groups, and everyone disagrees...

Of course, there is a deeper reason. We use such debugging commands because we essentially want to know the status of the kernel. In fact, the kernel has changed the entire principle of the networking module. On the other hand, I also require the command to display information as before. The format of the display level has deviated from the real principle. Therefore, in the long run, it is inevitable to replace these two commands.

in conclusion

Those of us who work in technology should also keep up with the times. Although the previous commands are familiar, easy to use, and even unforgettable, we still need to keep learning new ones. Many distributions no longer come with the net-tools package by default. Although it can still be installed manually, the attitude behind this is very clear. On the other hand, when we work in technology, we must also be careful not to let our brains become rigid and we must maintain our curiosity and enthusiasm for new things.

Well, that’s all for this article. I hope the content of this article will be of certain reference value to your study or work. Thank you for your support of 123WORDPRESS.COM.