Category:

Command Line Interface (CLI)

A command-line interface or command language interpreter (CLI), also known as command-line user interface, console user interface, and character user interface (CUI), is a means of interacting with a computer program where the user (or client) issues commands to the program in the form of successive lines of text (command lines).

How to Automatically Restart Failed Services in Linux Using systemd - blackMORE Ops - 1

How to Automatically Restart Failed Services Using systemd

by blackMOREOps April 24, 2025

written by blackMOREOps

When running production servers, ensuring your critical services stay up and running is essential. Service failures can happen for various reasons — memory issues, unexpected crashes, or resource limitations. Fortunately, modern Linux distributions include systemd, which offers built-in functionality to automatically restart failed services without requiring constant manual intervention.

Server reliability is crucial for maintaining uptime and providing consistent service to users. Learning how to automatically restart failed services using systemd is one of the most effective ways to improve system stability. Whether you’re running web servers like Apache or Nginx, database services like MySQL, or custom applications, unexpected failures can significantly impact your operations unless you configure systemd to handle recovery automatically.

This guide focuses on using systemd (the modern standard service manager in most current Linux distributions) to automatically restart failed services when they crash or terminate unexpectedly. We’ll walk through the process of configuring systemd to monitor and automatically restart services like MariaDB when they fail. If you’re looking for an alternative approach, you might also be interested in using Monit for service monitoring and automatic restarts.

Which Method Should You Choose?

There are two main approaches to automatically restarting services in Linux: systemd (covered in this guide) and Monit (a separate monitoring utility). Here’s how they compare:

Feature	systemd	Monit
Installation required	✅ No (built-in)	❌ Yes
Email notifications	❌ Requires extra setup	✅ Built-in
Web interface	❌ No	✅ Yes
Resource monitoring	⚠️ Limited	✅ Extensive
Configuration complexity	✅ Simple	⚠️ Moderate
Modern distributions support	✅ Excellent	✅ Good
Legacy system support	❌ Limited	✅ Excellent

Choose systemd if:

You’re running a modern Linux distribution
You need a simple, built-in solution
You’re primarily concerned with basic service restarts

Choose Monit if:

You need advanced monitoring features
You want email notifications
You’re running an older Linux distribution
You need to monitor resource usage or network connectivity

For details on implementing the Monit approach, see our guide on How to Automatically Restart Failed Services in Linux Using Monit.

Using systemd for Automatic Restarts

Systemd is the default init system and service manager in most modern Linux distributions (CentOS 7+, Ubuntu 16.04+, Debian 8+). It offers built-in functionality for monitoring and automatically restarting services without requiring additional software.

Finding Your Service Files

Before you can configure auto-restart, you need to locate the correct service file. The most reliable way to do this is by checking the service status:

sudo systemctl status mariadb.service

For example, with MariaDB you might see:

● mariadb.service - MariaDB 11.4.5 database server
   Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled; preset: enabled)
   Drop-In: /etc/systemd/system/mariadb.service.d
            └─limits.conf, migrated-from-my.cnf-settings.conf
   Active: active (running) since Thu 2025-04-24 06:34:22 UTC; 6min ago

The important line is Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled; preset: enabled), which tells you exactly where the service file is located.

Configuring Auto-restart

Once you’ve identified your service file, you have two options:

Option 1: Create an Override

This approach is best when working with system-provided service files:

sudo systemctl edit mariadb.service

This opens an editor where you can add just the settings you want to override. Add these lines:

[Service]
Restart=always
RestartSec=3s

When you save and exit, systemd will automatically create a drop-in file in /etc/systemd/system/mariadb.service.d/ and reload the configuration. However, sometimes it doesn’t work and you need to edit the service file directly.

Option 2: Edit the Service File Directly

If you’re creating a custom service file or if you really must edit a file directly, use the path from the status output:

sudo vim /usr/lib/systemd/system/mariadb.service

Add these lines to the [Service] section:

Restart=always
RestartSec=3s

Understanding Restart Options

The Restart directive offers several options:

always: Restart the service regardless of the exit reason (most comprehensive)
on-failure: Restart only if the service exits with a non-zero status or crashes
on-abnormal: Restart if the service was terminated by a signal or timed out
on-watchdog: Restart only if the watchdog timeout is triggered
on-abort: Restart only if the service dumps core
on-success: Restart only if the service exits cleanly with code 0
no: Never restart the service (default behaviour)

Complete Example: MariaDB Service

Here’s a complete example of auto-restart configuration for MariaDB. First, find the service file:

sudo systemctl status mariadb.service

This will show something like:

● mariadb.service - MariaDB 11.4.5 database server
   Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled; preset: enabled)

Now create an override:

sudo systemctl edit mariadb.service

Add these lines to the editor:

[Service]
Restart=on-failure
RestartSec=5s

When you save and exit, systemd will create the override file at /etc/systemd/system/mariadb.service.d/override.conf.

Verifying Your Configuration

After making your changes, you can verify the complete service configuration with:

systemctl cat mariadb.service

This will show both the original service file and any overrides you’ve created. You should see your Restart settings in the output.

Managing Your Service

After configuring auto-restart:

If you used systemctl edit, the changes are automatically applied. Otherwise, reload the systemd daemon:
```
sudo systemctl daemon-reload
```
Restart your service to apply the new configuration:
```
sudo systemctl restart mariadb.service
```
Enable the service to start automatically on boot:
```
sudo systemctl enable mariadb.service
```

Verifying Auto-restart Works

To confirm your service will restart automatically:

Check the service properties:

systemctl show -p Restart,RestartSec mariadb.service

Test the restart functionality:

sudo systemctl status mariadb.service  # Note the process ID
sudo kill -9 [process-id]              # Force kill the process
sudo systemctl status mariadb.service  # Verify it restarted automatically

Troubleshooting systemd Restarts

If you’re having issues with auto-restart:

Service doesn’t restart: Check journal logs with journalctl -u mariadb.service for errors
Continuous restart loops: If your service keeps failing and restarting, add these lines to limit restart attempts:
```
StartLimitIntervalSec=500StartLimitBurst=5
```
Permission issues: Ensure the service has proper permissions to restart

Conclusion

Automatic service restart capabilities are essential tools for maintaining high availability in Linux environments. Systemd offers a reliable, built-in solution that requires no additional software installation.

By implementing automatic restarts with systemd, you can significantly improve your server reliability and reduce downtime. No more manually restarting crashed services at 3 AM!

Take the time to properly configure automatic restarts for your critical services—it’s one of the simplest yet most effective ways to improve your system’s reliability.

April 24, 2025 0 comments

Command Line Interface (CLI)How to Linux Administration WordPress

How to Create a MySQL Database, Set User Permissions and Import SQLdump File

by blackMOREOps April 22, 2025

written by blackMOREOps

I’m sure you’ve been in that frustrating situation where you need to set up a database for your website, but can’t quite remember all those MySQL commands. Maybe you’re migrating a WordPress site to a new server, or perhaps you’re setting up a fresh environment and need to import SQLdump file. If you’ve searched around the interwebs for help, you’d know there’s plenty of overly complex guides that make this seem like rocket science. Most tutorials either assume you’re a complete beginner (and waste your time with unnecessary explanations) or they’re so advanced that you need a computer science degree to follow along. I just got fed up with this situation when I needed to quickly create a database, set up a user with proper permissions, and import a 2GB SQLdump file without the whole server timing out on me. So, in this guide, I’ll show you exactly how to create a MySQL or MariaDB database, set up users with passwords, restart MySQL when needed (because sometimes it just stops cooperating), and import those pesky SQLdump files – even the massive ones that make most import tools crash. No fluff, no unnecessary details, just the commands you need to get the job done.

To keep things practical, we’ll use a typical scenario: setting up a database for a WordPress site, creating a dedicated user with appropriate permissions, and importing a backup file. By the end of this guide, you’ll be able to handle these MySQL tasks quickly and efficiently. BTW, the commands are exactly same for MySQL or MariaDB like import SQLdump file or create DB or user manipulation etc.

Accessing the MySQL Command Line

Before creating a database, you’ll need to access the MySQL command line. Open your terminal and log in using the following command:

mysql -u root -p

You’ll be prompted to enter your MySQL root password. If you’ve just installed MySQL and haven’t set a root password yet, you might be able to log in without one.

Creating a New MySQL Database

Once logged in, create a database with:

CREATE DATABASE mydatabase;

Replace mydatabase with your preferred name.

Verify creation with:

SHOW DATABASES;

Setting Up Users and Permissions

Create a dedicated user:

CREATE USER 'newuser'@'localhost' IDENTIFIED BY 'password';

Grant permissions:

GRANT ALL PRIVILEGES ON mydatabase.* TO 'newuser'@'localhost';

Apply changes:

FLUSH PRIVILEGES;

Modifying User Passwords

Change a user’s password:

ALTER USER 'username'@'localhost' IDENTIFIED BY 'newpassword';
FLUSH PRIVILEGES;

Reloading MySQL Service

Restart MySQL after configuration changes:

Ubuntu/Debian:

sudo systemctl restart mysql

CentOS/RHEL:

sudo systemctl restart mysqld

macOS:

sudo launchctl unload -F /Library/LaunchDaemons/com.oracle.oss.mysql.mysqld.plist
sudo launchctl load -F /Library/LaunchDaemons/com.oracle.oss.mysql.mysqld.plist

Import SQLdump Files

Let’s get to the most critical part – import SQLdump files. This is often where things get tricky, especially with larger dumps. Here’s how to handle it properly:

From MySQL Command Line

For smaller files, you can import directly through the MySQL console:

USE mydatabase;
SOURCE /path/to/your/dumpfile.sql;

From Terminal (Better for Large Files)

For larger SQLdump files, this method is much more efficient:

mysql -u username -p mydatabase < /path/to/your/dumpfile.sql

This imports the SQLdump directly without loading it into memory all at once, preventing those annoying timeout issues.

For Very Large SQLdump Files

If you’re dealing with massive SQLdump files (like those 2GB+ monsters), you’ll need to adjust MySQL’s timeout settings before importing:

SET GLOBAL net_read_timeout=3600;
SET GLOBAL max_allowed_packet=1073741824;

These settings give MySQL enough time and memory to process large files without timing out. The max_allowed_packet setting is particularly important – it determines the maximum size of a packet or a generated/intermediate string, and the default is usually too small for large SQLdump imports.

Compressing SQLdump Files for Faster Import

For extremely large files, you can use compression to speed up the import:

gunzip < dumpfile.sql.gz | mysql -u username -p mydatabase

This decompresses the file on-the-fly while importing, saving both disk space and transfer time.

Troubleshooting SQLdump Imports

Let’s face it – SQLdump imports often fail the first time around. Here’s how to solve the most common issues:

Import Errors

If your SQLdump import fails with syntax errors, it’s likely due to version incompatibility. Check if your SQLdump was created on a newer MySQL version than the one you’re importing to. You can verify the MySQL version with:

SELECT VERSION();

Permission Denied

Nothing more frustrating than permission errors during a SQLdump import. Verify your user has all the necessary privileges:

SHOW GRANTS FOR 'username'@'localhost';

Make sure you see ALL PRIVILEGES or at least SELECT, INSERT, UPDATE, DELETE, CREATE, DROP permissions.

Import Taking Forever

For those massive SQLdump files that seem to import endlessly, you have a few options:

Split the SQLdump file into smaller chunks using the split command
Import only structure first, then data
Disable foreign key checks temporarily during import:

SET FOREIGN_KEY_CHECKS=0;
-- Import your SQLdump file here
SET FOREIGN_KEY_CHECKS=1;

Connection Issues

If MySQL keeps disconnecting during import, check if the service is running properly:

sudo systemctl status mysql

You might need to increase MySQL’s max_connection setting in my.cnf.

Conclusion

You’ve now got all the essential commands for creating MySQL databases and importing SQLdump files – even those massive ones that make most systems choke. The key takeaways here are: create your database first, set up a user with proper permissions, and use the right import technique based on your SQLdump file size. Remember that importing large SQLdump files isn’t just about running a command – it’s about preparing your MySQL environment with the right settings to handle the load. The max_allowed_packet and net_read_timeout settings are absolute lifesavers when dealing with hefty SQLdump files.

Always back up your databases before attempting any major changes or imports. Nothing worse than a half-imported SQLdump file corrupting your existing data. With these commands and techniques in your toolkit, you can confidently handle the core MySQL operations and SQLdump imports required for most website management tasks.

April 22, 2025 0 comments

Command Line Interface (CLI)How to Linux Linux Administration

Troubleshooting rsync SSH Authentication Issues

by blackMOREOps April 18, 2025

written by blackMOREOps

I’m sure you’ve bumped into situations where rsync just refuses to work over SSH even though your normal SSH connections work perfectly fine. This maybe happened right when you were in the middle of a critical backup or trying to sync important files between servers. If you’ve tried searching around the interwebs for solutions, you’d surely know there’s not many comprehensive guides available and most people would just casually tell you “check your permissions” or “use ssh-agent” without any real explanation.

Now, both might work, but I just got properly annoyed when dealing with a particularly stubborn case of rsync throwing that infamous “Permission denied (publickey)” error. The standard SSH connection worked flawlessly to the same server, but rsync just wouldn’t play nice. To make things worse, I was trying to sync a massive directory structure that I absolutely needed transferred yesterday, and every failed attempt wasted precious time.

This guide focuses specifically on troubleshooting those hair-pulling rsync SSH authentication issues on Ubuntu systems. Yeah, that means addressing all those weird edge cases where your keys seem to work fine for regular SSH but rsync decides to have a tantrum. I’ll walk you through the exact process to diagnose and fix these problems, especially for system administrators and developers who rely on rsync for efficient file synchronisation and can’t afford these random authentication failures.

Common SSH Authentication Problems with rsync

While direct SSH connections might work perfectly, rsync operations often encounter unique authentication challenges. The most common error message you’ll encounter is:

Permission denied (publickey)

This error typically occurs when:

The rsync command cannot locate or access your SSH keys
SSH agent configuration isn’t properly set up for rsync operations
Key permissions or formats are incompatible with the requirements
Remote server configurations restrict rsync specifically

These problems can be particularly frustrating because they might occur even when standard SSH connections to the same server work flawlessly.

Explicitly Specifying Your SSH Key for rsync

The most direct solution is to explicitly tell rsync which SSH key to use with the -e flag:

rsync -avzh --progress --ignore-existing -e "ssh -i /path/to/your/private_key" \
username@remote-server:/path/to/source/directory/ \
/path/to/destination/directory/

This approach bypasses any confusion about which key should be used by directly specifying the path to your private key file.

Ensuring ssh-agent Is Properly Configured

If you prefer using ssh-agent for key management, ensure it’s running correctly and has your key loaded:

eval $(ssh-agent)
ssh-add /path/to/your/private_key

You can verify the key has been added successfully with:

ssh-add -l

After confirming your key is loaded in the agent, try your rsync command again without explicitly specifying the key path.

Using the SSH Connection String Format

Sometimes, simplifying your rsync command by using the SSH connection string format can resolve authentication issues:

rsync -avzh --progress --ignore-existing \
"username@remote-server:/path/to/source/directory/" \
/path/to/destination/directory/

This format allows the SSH client to use its default authentication methods, which might solve issues when complex command structures interfere with authentication.

Checking for Permission Restrictions

The remote server might allow standard SSH connections but restrict rsync operations specifically. Verify these potential restrictions:

Directory permissions: Ensure the remote user has appropriate read/write permissions for the directories being accessed
SSH configuration: Check both ~/.ssh/config on your local machine and /etc/ssh/sshd_config on the remote server for any restrictions that might impact rsync
Available commands: Confirm that rsync is installed and accessible to the remote user
Command restrictions: Some SSH configurations use ForceCommand or similar restrictions in the authorized_keys file that might prevent rsync

Debugging with Verbose Output

When persistent authentication issues occur, enabling verbose output can provide valuable diagnostic information:

rsync -avvzh --progress --ignore-existing -e "ssh -v" \
username@remote-server:/path/to/source/directory/ \
/path/to/destination/directory/

The -v flag for SSH produces detailed output about the authentication process, helping identify exactly where the failure occurs. Adding multiple ‘v’s to rsync (e.g., -avvvzh) will increase rsync’s own verbosity levels.

SSH Key Conversion Issues

If you’re using keys that were originally in PuTTY’s .ppk format and converted them for use on Ubuntu, ensure they were properly converted. Improperly converted keys can work for basic SSH but fail with rsync.

For a complete guide on converting PuTTY keys for Ubuntu, refer to our detailed article on Converting PuTTY SSH Keys for Ubuntu.

Creating a Dedicated SSH Configuration

For persistent rsync connections, creating a dedicated entry in your SSH config file can resolve many authentication issues:

# Edit your SSH config file
nano ~/.ssh/config

# Add a dedicated host entry
Host backup-server
    HostName remote-server.example.com
    User username
    IdentityFile /path/to/your/private_key
    IdentitiesOnly yes

Then use this simplified rsync command:

rsync -avzh --progress --ignore-existing \
backup-server:/path/to/source/directory/ \
/path/to/destination/directory/

Conclusion

Troubleshooting rsync SSH authentication issues on Ubuntu requires systematic investigation of key access, configuration settings, and permissions. By explicitly specifying SSH keys, properly configuring ssh-agent, simplifying commands, checking permissions, and using verbose output for debugging, you can identify and resolve most authentication problems. For persistent issues, creating dedicated SSH configurations often provides a reliable long-term solution. With these techniques, you can ensure smooth rsync operations for your file synchronisation and backup needs on Ubuntu systems.

For more information on SSH key management, including security best practices, refer to our guide on SSH Key Management Best Practices.

April 18, 2025 0 comments

Atop vs Btop vs Htop vs Top - blackMORE Ops - 3

Command Line Interface (CLI)Linux Linux Administration

Atop vs Btop vs Htop vs Top: The Ultimate Linux Monitoring Tools Showdown

by blackMOREOps April 16, 2025

written by blackMOREOps

When it comes to keeping tabs on your Linux system’s performance, choosing the right monitoring tool can make all the difference between efficient troubleshooting and frustrating guesswork. From the classic ‘top’ command to more sophisticated alternatives like Atop, Btop, and Htop, Linux offers a range of options to suit different monitoring needs.

System administrators and power users alike need reliable tools to track resource usage, identify bottlenecks, and maintain optimal system performance. While these monitoring utilities share similar core functions, their approaches to presenting information, handling historical data, and user interaction vary significantly.

In this comprehensive guide, we’ll explore the strengths and weaknesses of top, atop, btop, and htop to help you determine which tool deserves a place in your Linux administration arsenal.

Quick Comparison Table

Feature	Top	Atop	Btop	Htop
Focus	Basic monitoring	Historical data logging	Modern UI with visual flair	Balanced functionality
UI Complexity	Minimal	Technical	Minimalistic	Moderate
Historical Data	None	Excellent	Limited	None
Resource Usage	Extremely low	Very low	Low	Low
Customisation	Limited	Moderate	Good	Excellent
Mouse Support	None	Limited	Full	Full
Process Management	Very basic	Basic	Good	Excellent
Learning Curve	Low	Steep	Gentle	Moderate

The Evolution of Linux Monitoring Tools

Top: The Original Workhorse

The venerable ‘top’ command has been the foundation of Linux system monitoring for decades. As the oldest and most basic option in our comparison, top represents the starting point from which all other monitoring tools have evolved.

Key Features:

Simple process monitoring displaying basic CPU and memory usage
Sortable process list allowing organisation by various metrics
Minimal resource overhead using almost no system resources itself
Universal availability pre-installed on virtually all Linux distributions
Basic process manipulation capabilities for sending signals

Advantages:

Available on any Linux system without additional installation
Extremely lightweight with negligible impact on system resources
Familiar to almost all Linux administrators
Reliable with decades of testing and refinement

Limitations:

Basic interface with limited visual information
No mouse support or modern navigation features
Minimal customisation options
No historical data retention

Best Use Case: Quick system checks on any Linux machine, particularly when working on unfamiliar systems where other tools may not be installed.

Atop: The Historical Data Champion

Atop elevates system monitoring by focusing on historical data retention and comprehensive resource tracking. It stands out as the go-to tool for system administrators who need to examine performance metrics over time.

Key Features:

Comprehensive resource monitoring with detailed metrics on CPU, memory, disk, and network usage
Historical data logging and analysis allowing review of system performance from hours or days ago
Minimal system impact ensuring accurate monitoring without significant resource consumption
Advanced per-process statistics including granular resource usage tracking
Automatic data logging capabilities that operate in the background

Advantages:

Unmatched for troubleshooting intermittent performance issues
Excellent for long-term system analysis and pattern identification
Superior disk I/O and network monitoring detail
Capable of identifying resource-intensive processes over extended periods

Limitations:

Technical interface with steep learning curve
Less intuitive navigation compared to modern alternatives
Limited interactive capabilities and visual representations

Pro Tip: Use Atop when investigating system issues that occur sporadically or when you need to analyse resource usage trends over time.

Btop: The Modern Visual Champion

Btop represents the newest evolution in terminal-based system monitoring, combining comprehensive data with striking visual presentation. Its modern approach makes system information both accessible and aesthetically pleasing.

Standout Capabilities:

Beautiful, intuitive interface with thoughtful information organisation
Full mouse interaction support for intuitive navigation
Real-time visualisations including graphs, charts, and heat maps
Comprehensive system overview combining CPU, memory, network, and disk in one view
Rich theme ecosystem including the popular Everforest theme

Advantages:

Most visually refined interface of all monitoring tools
Excellent balance of information density and readability
Accessible to both beginners and experienced administrators
Growing community support with active development

Limitations:

Slightly higher resource usage than traditional tools
Less historical data capability than Atop
As a newer tool, less extensively documented

Best For: Users who value visual clarity and modern design alongside powerful monitoring capabilities.

Htop: The Versatile All-rounder

Htop bridges the gap between traditional and modern approaches, enhancing the functionality of top while maintaining a familiar feel. It has become the default choice for many system administrators seeking reliable, interactive monitoring.

Notable Features:

Colour-coded process view for intuitive system state assessment
Tree view for process relationships displaying parent-child hierarchies
Extensive keyboard shortcuts for efficient operation
Robust process management with comprehensive signal options
Horizontal and vertical scrolling to access complete process information

Advantages:

Excellent balance of functionality and usability
Superior process management capabilities
Well-established with extensive documentation
Highly configurable to suit individual preferences

Limitations:

No built-in historical data capabilities
Less visually sophisticated than Btop
Requires more system resources than the original top

Why Choose Htop: Perfect for users who want enhanced monitoring capabilities with proven reliability and minimal learning curve.

Side-by-Side Feature Breakdown

1. User Interface Design

Top: Spartan, text-only interface with minimal visual organization. Displays a summary header and process list without graphical elements or color coding. The interface prioritizes information density over user experience.
Atop: Technical, data-dense interface with tabular presentation. Uses basic color highlighting for critical values but maintains a focus on comprehensive data presentation rather than visual appeal. Multiple specialized views can be toggled for different subsystems.
Btop: Modern, aesthetically pleasing design with thoughtful information hierarchy. Features elegant graphs, charts, and visual meters with smooth animations. Supports beautiful themes like Everforest that transform the monitoring experience into something genuinely enjoyable.
Htop: Functional interface with practical color coding and improved organization. Builds upon top’s familiar layout while adding visual clarity and better information grouping. Offers good readability without sacrificing technical detail.

2. Historical Data Capabilities

Top: No historical data capabilities. Provides only a real-time snapshot of current system state with no built-in way to track changes over time or review past performance.
Atop: Industry-leading historical data retention. Automatically logs comprehensive system metrics that can be reviewed and analyzed hours, days, or even weeks later. Includes detailed historical tracking of processes, disk I/O, network, memory, and CPU usage.
Btop: Limited historical context within the current session. Displays short-term trends via graphs but lacks persistent logging or the ability to review data from previous monitoring sessions.
Htop: No built-in historical data functionality. Focuses exclusively on real-time monitoring without tracking metrics over time.

3. Process Management Capabilities

Top: Basic process control with limited interaction. Allows sending signals to processes but with cumbersome keyboard commands and minimal filtering options.
Atop: Moderate process management focused on monitoring rather than control. Provides comprehensive process information with basic interactive capabilities for process manipulation.
Btop: Good process management with intuitive controls. Features mouse-based interaction for sending signals, adjusting priorities, and filtering the process list in a user-friendly manner.
Htop: Excellent process management toolkit. Offers comprehensive options for filtering, sorting, signaling, and managing processes with efficient keyboard shortcuts and mouse support.

4. Resource Monitoring Depth

Top: Basic monitoring of essential metrics. Shows CPU, memory, and process information with limited detail and no subsystem-specific views.
Atop: Comprehensive, detailed monitoring across all subsystems. Provides exceptionally granular data about CPU, memory, disk I/O, network, and process activity with specialized views for each subsystem.
Btop: Good all-around monitoring with visual context. Displays CPU, memory, network, and disk information in an integrated view with graphical representations that make patterns immediately apparent.
Htop: Solid monitoring focused on CPU and memory. Strong emphasis on process-related metrics with good detail but less comprehensive coverage of disk and network subsystems.

5. Customisation and Flexibility

Top: Minimal customisation with basic command-line options. Limited to sorting choices and update intervals with no persistent configuration.
Atop: Moderate customisation focused on data presentation. Offers configurable views and thresholds but with limited aesthetic or layout adjustments.
Btop: Good customisation with excellent theme support. Features configurable layouts, display options, and a growing ecosystem of community themes, including the stunning Everforest theme that transforms the monitoring experience.
Htop: Extensive customisation capabilities. Provides detailed control over column selection, color schemes, meters, and layout with persistent configuration options.

The Right Tool for Your Monitoring Needs

When to Use Top

You’re working on an unfamiliar system without administrative access
You need an absolutely minimal resource footprint
You require universal compatibility across all Linux distributions
You’re performing very basic system checks that don’t require detailed analysis
You’re writing scripts that need to parse simple system information

When to Use Atop

You need to investigate intermittent performance issues that occur unpredictably
Historical performance analysis is essential to your troubleshooting workflow
You require detailed disk I/O statistics for storage performance optimization
You need to correlate system events across different subsystems over time
You’re monitoring production servers where resource efficiency is critical

When to Use Btop (Our Recommendation)

You want a visually intuitive monitoring experience with modern design
You appreciate the importance of information design in system management
You desire a balance of powerful features and aesthetic presentation
You’d benefit from comprehensive system information in a unified view
You enjoy customizing your tools with themes like the beautiful Everforest theme

When to Use Htop

You need robust process management capabilities
You want a familiar top-like interface with significant enhancements
You require stable, well-tested software with extensive documentation
Process relationship visualization is important in your workflow
You prefer keyboard-driven operation with extensive shortcuts

Enhancing Btop with the Everforest Theme

One of the standout features of btop is its exceptional theme support. The Everforest theme transforms btop into not just a functional monitoring tool but a genuinely beautiful interface that’s a pleasure to use during long troubleshooting sessions.

Installing Everforest Theme for Btop

# Create themes directory if it doesn't exist
mkdir -p ~/.config/btop/themes

# Download the Everforest theme
curl -o ~/.config/btop/themes/everforest-dark-hard.theme https://raw.githubusercontent.com/iambeingtracked/btop-everforest/main/everforest-dark-hard.theme

# Launch btop
btop

Once btop is running:

Press “Escape” to access the menu
Navigate to “Options”
Select “everforest-dark-hard” from the theme dropdown

The Everforest theme features a soothing dark color palette that reduces eye strain while maintaining excellent contrast for readability. Its harmonious green and earth tones create a monitoring environment that’s both functional and visually refreshing.

Practical Usage Scenarios

To better illustrate when each tool shines, let’s examine some common system administration scenarios:

Daily System Health Checks

For routine system health monitoring, btop provides the most user-friendly experience. Its comprehensive dashboard layout gives you immediate visual feedback on all critical system metrics. The clear CPU, memory, network, and disk visualizations help identify potential issues at a glance, while the Everforest theme makes extended monitoring sessions comfortable.

Performance Troubleshooting

When investigating performance issues, particularly those that occur intermittently, atop is unrivaled. Its historical logging capabilities allow you to capture system metrics during off-hours and analyze them later. This is invaluable for tracking down issues that don’t manifest while you’re actively monitoring the system.

Resource-Constrained Environments

In extremely resource-limited systems or emergency situations, the original top command remains valuable. Its minimal footprint ensures it won’t compound resource issues on an already struggling system, and its universal availability means you’ll never be without basic monitoring capabilities.

Process Management

For administrators who frequently need to manage, kill, or reprioritize processes, htop offers the most comprehensive toolkit. Its intuitive process tree view, efficient keyboard shortcuts, and robust signaling capabilities make it the go-to choice for hands-on process management.

Conclusion: The Evolution of System Monitoring

The journey from top to the modern monitoring tools we have today represents an evolution in how we interact with and understand our Linux systems. While the venerable top command laid the foundation, atop, btop, and htop have each pushed the boundaries of what system monitoring can offer.

For most users, particularly those who value both functionality and aesthetics, btop represents the pinnacle of this evolution—especially when enhanced with the Everforest theme. Its beautiful interface doesn’t just make system monitoring more pleasant; it makes critical information more accessible and patterns more immediately apparent.

However, each tool in this comparison has earned its place in the Linux administrator’s toolkit. The original top continues to provide universal compatibility, atop offers unmatched historical analysis, and htop delivers robust process management with a familiar feel.

The best approach may be to become familiar with all four tools, using each one when its particular strengths align with your current needs. By mastering this suite of monitoring utilities, you’ll be well-equipped to handle any system performance challenge that comes your way.

April 16, 2025 0 comments

Command Line Interface (CLI)How to Linux Administration Ubuntu

Converting PuTTY SSH Keys for Ubuntu

by blackMOREOps April 16, 2025

written by blackMOREOps

When working across different operating systems, you’ll often encounter compatibility issues with SSH keys. PuTTY, a popular SSH client for Windows, uses its proprietary .ppk key format, which isn’t directly compatible with Ubuntu’s OpenSSH. This guide focuses on converting PuTTY SSH keys for seamless use on Ubuntu systems, helping you maintain secure connections without starting from scratch. Understanding the conversion process saves time and ensures your existing authentication setup continues functioning properly across platforms.

Understanding SSH Key Format Differences

Before diving into the conversion process, it’s important to grasp the fundamental differences between key formats:

PuTTY Keys: Stored in .ppk (PuTTY Private Key) format, these are designed specifically for the PuTTY suite of tools in Windows environments.
OpenSSH Keys: Used by Ubuntu and most Linux distributions, these typically appear as files without extensions or with .pem extensions.

These differing formats represent the same cryptographic information but are structured differently, making direct interchangeability impossible without proper conversion.

Why You Can’t Use PPK Files Directly in Ubuntu

If you’ve tried using your PuTTY .ppk files directly with Ubuntu’s SSH client, you’ve likely encountered errors. This incompatibility exists because:

Ubuntu’s SSH client is built on OpenSSH, which expects keys in its native format
The internal structure and encoding of .ppk files differ from what OpenSSH recognises
There are no built-in fallbacks to automatically detect and convert between formats

Attempting to use a .ppk file directly will result in permission denied errors, even if the credentials themselves are valid.

Step-by-Step Conversion Process

Converting your PuTTY keys to work with Ubuntu’s SSH client involves a straightforward process:

1. Install the Required Conversion Tools

First, ensure you have the necessary tools installed on your Ubuntu system:

sudo apt-get update
sudo apt-get install putty-tools

This installs the puttygen utility, which facilitates the conversion between different key formats.

2. Transfer Your PPK File

Transfer your existing .ppk file to your Ubuntu system using a secure method like SCP, SFTP, or a secure cloud storage solution.

3. Convert the Key to OpenSSH Format

Use the puttygen command to convert your PuTTY private key to OpenSSH format:

puttygen your-key.ppk -O private-openssh -o ~/.ssh/id_rsa

Replace your-key.ppk with the actual name of your PuTTY key file.

4. Generate the Public Key

Next, create the corresponding public key from your newly converted private key:

ssh-keygen -y -f ~/.ssh/id_rsa > ~/.ssh/id_rsa.pub

5. Set Appropriate File Permissions

SSH is very particular about file permissions for security reasons. Set them correctly with:

chmod 600 ~/.ssh/id_rsa
chmod 644 ~/.ssh/id_rsa.pub

6. Test Your Connection

Now you can test your connection using standard SSH commands:

ssh username@destination-server

7. Add the Key to Your SSH Agent

For convenience, add your key to the SSH agent so you don’t need to specify it each time:

eval $(ssh-agent -s)
ssh-add ~/.ssh/id_rsa

Verifying Your Converted Key

After completing the conversion, it’s wise to verify that your key works as expected:

Test a basic SSH connection to ensure authentication succeeds
Try copying files using SCP to confirm the key works for file transfers
Verify that automated scripts using the key function correctly

If you encounter any issues during verification, double-check your conversion steps and ensure file permissions are set correctly.

Conclusion

Converting PuTTY SSH keys for use on Ubuntu systems bridges the gap between different operating systems and maintains your secure connections. By following the straightforward conversion process outlined above, you can continue using your existing keys without generating new ones or compromising security. The conversion from .ppk to OpenSSH format ensures compatibility with Ubuntu’s native SSH client while preserving all the security benefits of key-based authentication.

For more advanced SSH key management or troubleshooting authentication issues with tools like rsync, check out our related guides on Troubleshooting rsync SSH Authentication Issues and SSH Key Management Best Practices.

April 16, 2025 0 comments

Newer Posts

Older Posts