In Linux, there’s a certain set of commands that are used most frequently by virtually all administrators. For example, commands like ls, cd, grep, top, df, and ps are probably familiar even to those who open a terminal only a couple of times a month. Commands such as awk, sed, find, and systemctl are used slightly less often, but they, too, are part of an administrator’s standard toolkit.
However, there is also a second tier of tools that solve very practical problems; just like the first tier, they are often already installed on the system*, though they’re usually only remembered after twenty minutes of fiddling with grep, pipes, or reading /proc.
We’ve selected ten Linux commands specifically from this category to remind you of them and show how they can come in handy when administering a server, troubleshooting, or just working in the console. Let’s refresh our memories and get reacquainted with some of them.
*A small caveat. The set of preinstalled utilities depends on the distribution and installation type. In minimal installations of Ubuntu/Debian, AlmaLinux/Rocky, and especially in containers, some commands may be missing. In such cases, the necessary package can be installed from the standard repository. It’s also worth mentioning that in this article we’re providing an overview of all the commands, so to speak, while a complete list of their options is always available for you to explore on your own via
man <command>or the utility’s online documentation.
1. stat
How do you usually view information about a file? Of course, with the ls command, like this:
ls -l backup.tar.gz
For most tasks, this is more than enough. But sometimes you want to get information about the inode in one place, see the file permissions in numerical form, or figure out when the file was actually last modified. In that case, the stat command comes in handy:
stat backup.tar.gz
Its output will look something like this:
File: backup.tar.gz Size: 104857600 Inode: 1849231 Access: (0644/-rw-r--r--) Access: 2026-09-30 08:41:12 Modify: 2026-09-28 03:15:44 Change: 2026-09-29 12:06:18
Of particular interest here are three timestamps: Access, Modify, and Change, which indicate, respectively, the date and time of the last access to this file, the date and time of the last modification to the file’s contents, and the date and time of the last change to the file’s metadata.
The difference between the second and third parameters is that, for example, after running the chmod command, the file’s contents will remain the same, but the ctime will change, which will be reflected in the Change parameter. Such a small detail can sometimes help you understand what happened to a suspicious file.
You can also specify the output format for this command, which can be convenient for use in scripts and pipelines:
stat -c "%n %s %a %U:%G" *
When executed this way, the command outputs the file name, size in bytes, permissions, and owner without the need to parse the output of a simple ls.
2. ss
Undoubtedly, the good old netstat is still found in instructions from a decade ago. But in modern Linux systems, the ss command-short for Socket Statistics-is increasingly used for many of its tasks.
For example, the following command will show TCP and UDP sockets, listening ports, and the processes associated with them:
ss -tulpn
Therefore, the question of who is using port 8080 can be answered briefly:
ss -ltnp | grep ":8080"
You might get a response like this:
LISTEN 0 4096 0.0.0.0:8080 0.0.0.0:* users:((" java", pid=2841, fd=47))
Now it’s clear where to look next, since we can see that the port is held by the java process with PID 2841.
Here are a couple more useful examples:
ss -tn state established
will show established TCP connections, and:
ss -s
will provide brief network statistics.
When dealing with network issues, ss often lets you see in a matter of seconds what would otherwise take significantly longer to find using several other commands.
3. lsof
The name of this utility stands for "List Open Files”. Sounds a bit boring, doesn’t it? But that’s only until we remember just how broadly Linux interprets the concept of a file. Therefore, the scope of the lsof command goes far beyond simply viewing currently open files.
For example, if you need to find out who is using a specific port, type the following command:
lsof -i :443
To see who is holding a specific file:
lsof /var/log/nginx/access.log
To see which files a specific process has open:
lsof -p 1234
To give a clear, concrete example, imagine you have a server that generates logs which are filling up disk space. You deleted the largest log file, but the disk space hasn’t been freed up. In this case, run the command:
lsof +L1
And in the output, you might see something like this:
COMMAND PID USER FD SIZE/OFF NAME java 2841 app 12w 18G /var/log/app.log (deleted)
This means that the file itself is no longer in the directory, but the process continues to hold an open file descriptor, and until it closes it, the occupied space may not be freed up.
It’s precisely for cases like this that the lsof command is definitely worth remembering.
4. watch
If you just need to observe for a couple of minutes whether the server’s status is changing right now, you don’t need to set up any monitoring systems-like Prometheus or Grafana-or build a big dashboard.
For this, there’s a simple command watch, which shows changes in various parameters "live". For example, to monitor used RAM, run:
watch -n 2 free -h
Every two seconds, free -h will be rerun, and the screen will automatically refresh.
You can also monitor disk usage:
watch -n 2 "df -h /"
Or check the status of a specific service:
watch -n 1 "systemctl is-active nginx"
It’s especially convenient to use the -doption, which highlights changes between updates:
watch -d -n 1 "ss -s"
This creates a simple little monitor from virtually any console command. For example, let’s say we’ve started copying a large file, running a backup, or some other time-consuming process-and we’re keeping an eye on disk space usage.
5. timeout
Sometimes you run a command without knowing in advance how long it will take to complete-after all, the connection to a network resource might be lost, a script might hang or enter an infinite loop, and so on. Therefore, it’s better to limit the execution time right away:
timeout 30s ./script.sh
And if the process is still running after 30 seconds, then timeout will force it to stop.
Here are a couple more examples-you can figure out the tasks for yourself:
timeout 10s ssh server.example.com uptime
Or:
timeout 5s curl https://example.com
Also, after the timeout is triggered, you can check the exit code by running:
timeout 3s sleep 10 echo $?
which will return:
124
This way, the script can determine that the command terminated specifically because the specified time limit was exceeded.
Using the timeout command works particularly well in automation scenarios, such as when your Cron job or service script shouldn’t hang indefinitely just because a single external resource has stopped responding.
6. fuser
This tool overlaps slightly in purpose with lsof, but returns results in a shorter format.
For example, the command:
fuser /var/log/app.log
might return:
/var/log/app.log: 2841
As a result, we see the PID of the process using the file.
It works similarly with ports:
fuser 8080/tcp
And for a more detailed output, there’s the -voption:
fuser -v 8080/tcp
The result will look something like this:
USER PID ACCESS COMMAND 8080/tcp: app 2841 F.... java
Now both the user and the process are visible.
fuser also has the -k option, which allows you to terminate the found processes. But it’s best not to rush into this, especially as root, so as not to crash the system.
To summarize: if you need a detailed report, it’s usually more convenient to use lsof, but if you want to link a file or port to a PID in a couple of seconds, fuser is perfect.
7. pstree
When working with processes, it’s often necessary to view all the processes running on the system. For this, the standard command ps aux is most commonly used, which displays all processes as a simple, long list. It becomes difficult to determine the relationships between them without using additional utilities. The pstree command, however, immediately builds a process tree in a visual format.
Let’s try it:
pstree -p
Instead of a boring table, you’ll get a tree that immediately shows who started whom:
systemd(1) ├─sshd(821) │ └─sshd(1532) │ └─bash(1540) └─nginx(902) ├─nginx(903) └─nginx(904)
You can also examine a specific process:
pstree -p 1532
Or view its parents:
pstree -sp 1540
This is especially useful when working with daemons, shell scripts, worker processes, and applications that spawn a whole family of child processes.
8. journalctl -b -1
Yes, the journalctl system log itselfhas long been an open secret. But some of its capabilities are remembered much less often. For example, one of the most useful ways to use it is to view the log of the last system reboot using the following parameters:
journalctl -b -1
For example, your server froze or unexpectedly rebooted during the night, and after the restart, everything is working as before. Events after the restart are already being written to the current log, although we’re specifically interested in what happened before it.
You can also filter the output to see only warnings or errors:
journalctl -b -1 -p warning
And you can view the kernel messages from the previous boot like this:
journalctl -k -b -1
There, you may find traces of OOM conditions, disk errors, driver issues, or other events that occurred immediately before the crash.
When troubleshooting system issues, it’s very helpful to know one more command:
journalctl --list-boots
It will display the saved system boots in the following format:
IDX BOOT ID FIRST ENTRY LAST ENTRY -2 d65a9269caee412bb6a8d887c8fc0678 Thu 2026-07-30 18:38:31 EEST Sun 2026-08-02 17:21:18 EEST -1 415be0912ce04afdb422362c1c514a99 Sun, Aug 2, 2026, 5:21:37 PM EEST Fri, Sep 11, 2026, 9:40:58 AM EEST 0 347bca10383740be9f5e5d6306dbc02f Sun, September 13, 2026, 6:36:18 AM EEST Wed, September 30, 2026, 3:22:51 PM EEST
9. xargs
When working with the Linux console, it’s often necessary to take the output of one command and pass it to another command. For example, to find dozens of files and then delete them, check them, or perform some action on each one. A standard pipeline using | doesn’t always work, since one program might output a list of data, while the next one expects it as command-line arguments.
That’s exactly why xargs exists. It takes the received data, converts it into arguments, and runs the specified command with them.
Let’s imagine that the file hosts.txt contains the addresses of several servers:
server1.example.com server2.example.com server3.example.com server4.example.com
We need to check each of them using the ping command. To do this, we read the list of these servers on the left side and pass them to the ping command on the right side:
cat hosts.txt | xargs -n 1 ping -c 1
The -n 1 parameter tells xargs to pass one address at a time to the command. As a result, each server in the list will be checked sequentially.
If there are many servers, the task can be parallelized:
cat hosts.txt | xargs -P 4 -n 1 ping -c 1
The -P 4 option allows up to four ping processes to run simultaneously. This technique is useful not only for checking servers, since xargs can be used to batch-process files, run scripts on a list of objects, or pass a large set of results to another program.
However, there is a small caveat when working with files. For example, if a filename contains a space, passing the list in the usual way may incorrectly interpret a single filename as several separate arguments.
For instance, a safe way to search for errors in all .log files at once would look like this:
find . -name ‘*.log’ -print0 | xargs -0 grep ‘ERROR’
Here, find finds all files with the .log extension, and xargs passes them to the grep command, which searches for the string ERROR within them. The -print0 and -0 options are needed here to handle filenames containing spaces correctly. For example, the file old server.log will remain a single file, rather than being split into old and server.log.
10. systemd-analyze
Let’s return to troubleshooting server issues; in this case, we’ll examine a scenario where the server takes a long time to boot after a restart or power-on. Suppose your server takes five minutes to boot, and you have no idea what exactly is causing the delay.
In this case, you should first check the total boot time using the command:
systemd-analyze
Next, we need to get a list of unit files and the duration of their execution:
systemd-analyze blame
Result:
21.304s NetworkManager-wait-online.service 8.411s mariadb.service 4.281s docker.service 2.930s cloud-init.service
It might seem like we’ve found the culprit. But a long duration next to a particular service doesn’t necessarily prove that it’s the one causing the entire boot process to stall, since many unit files run in parallel.
That’s why there’s another, "magical”, command:
systemd-analyze critical-chain
It shows the critical boot chain-specifically, the dependencies that actually affected the system’s ability to reach the desired state.
systemd-analyze also has a more visual mode-a command that can generate a graph of the system boot process:
systemd-analyze plot > boot.svg
Running this command will generate a file named boot.svg, which you can open in a standard web browser. The graph will show when individual services started and how long each one took. So if a server takes a long time to boot, this graph lets you visually identify long delays and see which services were running at that moment.
We covered the issue of slow-booting Linux servers in more detail in a separate article.
Quick Cheat Sheet
So, we’ve reviewed 10 commands that can make life much easier for any Linux administrator. Of course, memorizing dozens of options for each of these commands is pointless. It’s enough to at least remember that the right tool exists so that, if necessary, you can dig a little deeper. And to make it easier to remember, here’s a simple cheat sheet:
| Task | Command |
|---|---|
| View detailed file metadata | stat |
| Check sockets and network connections | ss |
| Find the process that opened a file or port | lsof |
| Repeat a command at regular intervals | watch |
| Limit command execution time | timeout |
| Quickly find a PID by file or port | fuser |
| View the process hierarchy | pstree |
| Examine the previous system boot | journalctl -b -1 |
| Pass a set of arguments to another command | xargs |
| Analyze system boot performance | systemd-analyze |
FAQ
Are all of these commands available in every Linux distribution?
No. Most of them are available in the standard repositories of popular distributions, but some utilities may be missing in a minimal installation or container. In that case, simply install the corresponding package using the package manager.
Where can I find all the features of a specific command?
In the man help system or in the official documentation for a specific utility on the internet. This article lists only the most illustrative use cases, but most of these commands offer far more capabilities.
How does fuser differ from lsof?
fuser is useful for quickly finding a process that is using a specific file or port. lsof displays more detailed information about open files, processes, and network connections. The choice depends on how detailed a response you need.
Why do some commands show more information when run as root?
A regular user does not have access to all information about other users’ processes and the resources they have open. Therefore, diagnostic utilities sometimes provide a more complete picture when run with root privileges.
Can these commands be used on VPS and dedicated servers?
Yes. These are standard Linux utilities, so they work equally well on VPS, physical servers, and local Linux machines. Limitations may only arise in containers or heavily stripped-down systems.
Which of these commands are particularly useful for diagnosing server issues?
For network issues, ss, lsof, and fuser are useful; after an unexpected reboot, use journalctl; and systemd-analyzehelps identify the causes of slow boot times. stat, watch, timeout, pstree, and xargsare more often used for more specific tasks.
