In this article we have a look at obtaining some basic hardware, system and operating system configuration information directly from the command prompt in your terminal. Having this information, and knowing where to find it, often helps when configuring a system, researching optimal hardware and software solutions, and generally being in control of the Linux system you own or manage.
We will focus mostly on every day information, the kind that is required on a regular basis. Going more in-depth often requires a few online searches to first define alignment better, and then often requires additional skills to interpret the results or output shown.
For example, we will not be looking at the output of vmstat, though we will discover how to find out what CPU is in your system without opening the hood. We will also look at some basic resource limit variables and surrounding concerns. The target audience for this article is thus beginner to medium advanced.
This article is part of the Useful Bash Command Line Tips and Tricks Series.
In this tutorial you will learn:
- Useful Bash command line tips, tricks and methods
- How to interact with the Bash command line in an advanced manner
- How to sharpen your Bash skills overall and become a more proficient Bash user
Software requirements and conventions used
| Category | Requirements, Conventions or Software Version Used |
|---|---|
| System | Linux Distribution-independent |
| Software | Bash command line, Linux based system |
| Other | Any utility which is not included in the Bash shell by default can be installed using sudo apt-get install utility-name (or yum install for RedHat based systems) |
| Conventions | # – requires linux-commands to be executed with root privileges either directly as a root user or by use of sudo command$ – requires linux-commands to be executed as a regular non-privileged user |
Example 1: What CPU is in your system?
Often, we want to quickly find out what CPU is in the system, without opening the box. Opening the physical computer is also a bit hard if you are managing a server on the other side of the planet. Finding out the CPU details is easy and straightforward:
$ cat /proc/cpuinfo | grep 'model name' | head -n1 model name : Intel(R) Core(TM) i9-9900K CPU @ 3.60GHz $ cat /proc/cpuinfo | grep 'model name' | wc -l 16
In the first command, we queried the dynamic /proc/cpuinfo file which lists the current CPU as detected by the operating system. There are 16 lines (as seen in the second command) of exactly the same output, so we only list the first line using the head -n1 command. Note that we could also write these commands as follows:
$ grep 'model name' /proc/cpuinfo | head -n1 model name : Intel(R) Core(TM) i9-9900K CPU @ 3.60GHz $ grep 'model name' /proc/cpuinfo | wc -l 16
You may however want to use the cat method to explore the full output (cat /proc/cpuinfo) as there is a lot of interesting information displayed about your processor. The 16 count is due to there being 16 threads in this particular CPU, so the operating system sees it as 16 individual processors, or threads, to use.
Finding Out Your OS and Release
Often when managing a remote server, we want to make sure it is patched to the right revision of an operating system. To find out more what operating system your machine is using, and what revision it is at, simply execute cat /etc/*release*:
$ cat /etc/*release* DISTRIB_ID=Ubuntu DISTRIB_RELEASE=20.04 DISTRIB_CODENAME=focal DISTRIB_DESCRIPTION="Ubuntu 20.04.1 LTS" NAME="Ubuntu" VERSION="20.04.1 LTS (Focal Fossa)" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu 20.04.1 LTS" VERSION_ID="20.04" HOME_URL="https://www.ubuntu.com/" SUPPORT_URL="https://help.ubuntu.com/" BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/" PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy" VERSION_CODENAME=focal UBUNTU_CODENAME=focal
To compare, here is the output from the same command on a Raspbian based Raspberry Pi 4:
$ cat /etc/*release* PRETTY_NAME="Raspbian GNU/Linux 10 (buster)" NAME="Raspbian GNU/Linux" VERSION_ID="10" VERSION="10 (buster)" VERSION_CODENAME=buster ID=raspbian ID_LIKE=debian HOME_URL="http://www.raspbian.org/" SUPPORT_URL="http://www.raspbian.org/RaspbianForums" BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"
Once you remember this shorthand, you will soon find yourself using it many situations. The actual files shown here, at least on Ubuntu, are: /etc/lsb-release and /etc/os-release. On Raspbian there is only /etc/os-release.
Operating vs System Limits
A lot of operating system limits are implemented by default in Linux. They are set in a crafty manner, as you will often not run into them until you are a DevOps or similar engineer maximizing the throughput of a set of remote servers.
Changing these operating system variables requires some knowledge about each of them, and setting them may at times require some testing to establish reasonable boundaries.
Another consideration here is that system limits may be hit long before a operating system configured limit is hit, and this is especially true if you set such operating system limits to a very high number. This is also why such operating system limits are there in the first place: to limit the operating system from loosing control over a physical system resource (disk, ram, memory, CPU) due to a poorly managed cap / limit.
Thus, changing an operating system based limits comes with various risks. Not only is it rather easy to set them too large resulting in the operating system often loosing control of specific resources, but changing some variables also carries with it some security risks.
For example, let’s say that a hacker would throw a fork bomb at the system. A fork bomb is not a real bomb, but rather a software based exploit which results in the system repetitively forking new shells and threads towards one ‘fork bomb’ organizing process. If the number of allowed forks had somehow been modified by changing one or more system variables, the system could soon run out of CPU resources trying to fork-till-infinity.
Another aspect to consider here is how secure the server or workstation you are managing is to start with. If it is in a DMZ zone in a data center, otherwise isolated from other servers, and used for low privilege tasks (like testing) only, it may be quite acceptable to set rather high limits. If that same server was pushing production code and is signing release packages, a whole lot more careful system resource management would be advised.
You can see how changing these variables requires some expertise and experience. Still, most of them are easy to understand, and have common English names.
The most common ones are set in /etc/security/limits.conf. For example, to greatly increase the maximum number of open files to the 300000, you can add the following lines to /etc/security/limits.conf:
* soft nofile 300000 * hard nofile 300000
This will 300k files to be opened at once. The maximum which can be set for these variables is 1048576.
Note that there is a difference between ‘soft’ and ‘hard’ limits: hard limits can only be raised further by root level access, whereas any process can lower the limit. This is great for security purposes as non-root processes will not be able to overstep a limit. A soft limit can be changed by a given process at any time.
There are many other similar settings which can be changed from within this file. To get a broad idea, you can use ulimit -a to see the limits applicable to your system at this point in time.
The next most prominent file when it comes to tuning system resources is /etc/sysctl.conf. In this file, it is possible to finetune many kernel parameters. For example, to set the maximum number of PID’s (process identifiers) to 500k and the swappiness of your system (how easily the operating system will exchange memory based information with disk based information – also named ‘swapping’) to 5 (a setting which restricts swapping considerably), you can add the following to /etc/sysctl.conf:
kernel.pid_max=500000 vm.swappiness=5
We do not recommend implementing any of the settings shown above without further research, and tuning then specifically to your system. Often raising a variable to a higher setting will not produce any issues, unless an unforeseen event happens, like the hacker example discussed earlier.
Conclusion
In this article, we looked at how our operating system keeps resources under control, and what the main configuration files in connection with this are. We also discovered how to find out what CPU is in the system, and what operating system and it’s version we are using. Knowing these basic things, one can explore further into specific settings made in /etc/security/limits.conf and /etc/sysctl.conf and manage Linux based systems more confidently. Enjoy!
