Search icon CANCEL
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Conferences
Free Learning
Arrow right icon
Arrow up icon
GO TO TOP
The Software Developer's Guide to Linux

You're reading from   The Software Developer's Guide to Linux A practical, no-nonsense guide to using the Linux command line and utilities as a software developer

Arrow left icon
Product type Paperback
Published in Jan 2024
Publisher Packt
ISBN-13 9781804616925
Length 300 pages
Edition 1st Edition
Tools
Arrow right icon
Authors (2):
Arrow left icon
Christian Sturm Christian Sturm
Author Profile Icon Christian Sturm
Christian Sturm
David Cohen David Cohen
Author Profile Icon David Cohen
David Cohen
Arrow right icon
View More author details
Toc

Table of Contents (20) Chapters Close

Preface 1. How the Command Line Works 2. Working with Processes FREE CHAPTER 3. Service Management with systemd 4. Using Shell History 5. Introducing Files 6. Editing Files on the Command Line 7. Users and Groups 8. Ownership and Permissions 9. Managing Installed Software 10. Configuring Software 11. Pipes and Redirection 12. Automating Tasks with Shell Scripts 13. Secure Remote Access with SSH 14. Version Control with Git 15. Containerizing Applications with Docker 16. Monitoring Application Logs 17. Load Balancing and HTTP 18. Other Books You May Enjoy
19. Index

Review – example troubleshooting session

Let’s look at an example troubleshooting session. All we know is that one specific Linux server is running extremely slowly.

To begin with, we want to see what’s happening on the system. You just learned that you can see a live view of processes running on a system by running the interactive top command. Let’s try that now.

Figure 2.9: Example of output of the top command

By default, the top command sorts processes by CPU usage, so we can simply look at the first listed process to find the offending one. Indeed, the top process is using 94% of one CPU’s available processing time.

As a result of running top, we’ve gotten a few useful pieces of information:

  • The problem is CPU usage, as opposed to some other kind of resource contention.
  • The offending process is PID 1763, and the command being run (listed in the COMMAND column) is bzip2, which is a compression program.

We determine that this bzip2 process doesn’t need to be running here, and we decide to stop it. Using the kill command, we ask the process to terminate:

kill 1763

After waiting a few seconds, we check to see if this (or any other) bzip2 process is running:

pgrep bzip2

Unfortunately, we see that the same PID is still running. It’s time to get serious:

kill –9 1763

This orders the operating system to kill the process without allowing the process to trap (and potentially ignore) the signal. A SIGKILL (signal #9) simply kills the process where it stands.

Now that you’ve killed the offending process, the server is running smoothly again and you can start tracking down the developer who thought it was a good idea to compress large source directories on this machine.

In this example, we followed the most common systems troubleshooting pattern in existence:

  1. We looked at resource usage (via top in this example). This can be any of the other tools we discussed, depending on which resource is the one being exhausted.
  2. We found a PID to investigate.
  3. We acted on that process. In this example, no further investigation was necessary and we sent a signal, asking it to shut down (15, SIGTERM).
You have been reading a chapter from
The Software Developer's Guide to Linux
Published in: Jan 2024
Publisher: Packt
ISBN-13: 9781804616925
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at €18.99/month. Cancel anytime