Linux offers a rich set of tools for reading, inspecting, and displaying file content from the command line. Whether you’re paging through a large log file, searching for patterns with grep, or navigating a file in vim, the shell gives you precise control over how content is viewed.

This guide covers the essential techniques for viewing files in Linux: from core pagers and readers to text searching, Vi/Vim navigation, file comparison, and tools for opening specialized formats like EPUB, PDF, HEIC, and CAD files.

Viewing and Reading File Content

• Viewing Files in Linux Using cat, more, and less
• Differences Between more, less, and most in Linux
• Display the First “n” Characters of a File in Linux
• Printing Specified Lines From a File
• How to Read the First and the Last Line From Input
• Adding Syntax Highlighting for the less Command
• Using the tail Command with Colored Output

Searching and Filtering Text

• Difference Between CR LF, LF, and CR Line Break Types
• grep – How to Output Only the Content of a Capturing Group
• How to Find File Encoding in Linux
• Limiting the Output of grep
• Show Only the N-th Line After the Match
• Using grep After a Specified Line Number

Navigating and Viewing in Vi and Vim

• Basic Vi Navigation and Scroll
• Basic and Advanced Searching in Vi
• Character Navigation or How to Jump to a Specific Character in Vi
• Displaying the Full Path of the Current File in Vim
• How to Clear Word Highlighting in Vim
• How to Make Vim Remember the Last Edit Position
• Working With Vim Windows

Comparing and Inspecting Files

• How to View the Contents of tar.gz Without Extracting It
• How To Compare Two Directories on Linux
• How to Test tar File Integrity
• Comparing Two Files in Linux
• Comparing tar Files in Linux
• How to Color the Output of diff
• Displaying Files Side by Side in Linux

Viewing Specialized File Formats

• View Images from the Terminal in Linux
• EPUB Viewer Tools in Linux
• Linux Optical Character Recognition (OCR) Tools
• How to Open .dwg Format in Ubuntu
• How to View .HEIC Photos on Linux
• Opening .dmg Files on a Linux System
• How to Check PDF Metadata in the Linux Terminal
• How to View a .msg File in Linux

The post Linux File Viewing Series first appeared on Baeldung on Linux.

      

Related Stories

• How To Open Visio Files in Linux
• Linux File Editing Series
• How to View Font Files in Linux

 

1. Overview

GIMP (GNU Image Manipulation Program) is a free, open-source image editor for tasks ranging from simple drawing to professional photo retouching. It offers layers, brushes, selection tools, and filters like a basic paint app or an advanced photo-editing suite.

While working in GIMP, sometimes we need to swap colors, such as when modifying a logo using a new color scheme, adjusting a photo’s palette, or just having fun experimenting. Whatever the reason, we can apply these changes in GIMP using simple methods.

In this tutorial, we’ll explore multiple methods to swap colors in GIMP.

2. Using the Color Exchange Tool

We can use the Color Exchange tool to directly replace one color with another. It works best on images with clear, solid colors or when we define the color that we want to replace.

To swap one color with another, we first open our image and ensure the correct layer is selected. Then, we go to Colors > Map > Color Exchange:

A dialog box appears where we choose the color we want to replace by clicking the From Color swatch. Alternatively, we can use the eyedropper to select the color from the image. Next, we click the To Color swatch and choose the new color we want to apply:

If the color in our image has variations, like shadows or highlights, we can fine-tune the change using the Red, Green, and Blue threshold sliders. These sliders control how closely a pixel’s color must match the original for it to be replaced. Lower values will replace only exact matches, while higher values allow for broader color replacements. Once we’ve set everything, we click OK to apply the changes:

Here, because the threshold value is slightly higher, the image swaps colors over a broader area and may mix with other colors. To correct this, we can lower the threshold value from 0.500 to 0.2 or 0.3 so that only exact matches are replaced:

Furthermore, this method works best for simple graphics with flat, solid colors. It might not be ideal for detailed photos or images with complex textures, but it’s quick and effective for basic color swaps.

3. Using the By Color Select Tool

In GIMP, we can also use the By Color Select tool to change specific colors in an image, with more control than automatic color replacement. This method involves selecting all pixels of a specific color first, then changing the color of the selection.

First, we open our image and choose the By Color Select tool from the toolbox, or we simply press Shift+O on the keyboard:

Then, we click on the color in our image that we want to change. GIMP selects all matching pixels based on the threshold setting, which we can adjust in the Tool Options. Again, a lower threshold selects only very similar colors, while a higher threshold includes a broader range of shades.

Furthermore, if we want to refine the selection, we can hold Shift to add more colors or Ctrl to remove areas from the selection. For softer edges, we can go to Select > Feather and choose a small value, like 2 or 3 pixels.

Once the selection looks right, we go to Colors > Colorize to apply a new color. Here, we can adjust the Hue, Saturation, and Lightness sliders, or click the color bar to pick an exact color using RGB or HEX values. After we’re satisfied with the preview, we click OK to apply the changes:

Alternatively, instead of using Colorize, we can pick the Bucket Fill tool, select a new foreground color, and click inside the selected area to fill it directly:

When done, we press Ctrl+Shift+A to deselect and view the results. This method is especially useful for images with patterns, shading, or complex textures where we need precise color control.

4. Using Layer Masks for Non-Destructive Swapping

We can also use layer masks in GIMP to swap or recolor parts of an image with more precision. For example, to start, we open our image in GIMP and duplicate the original layer. This helps us preserve the original image while we work on a copy.

Next, we use a selection tool like By Color Select or Fuzzy Select to isolate the area we want to recolor. If the object has a solid color, the By Color Select tool usually works best. We click on the target area and adjust the threshold if needed, so only the desired region gets selected.

Once the area is selected, we right-click on the duplicated layer and choose Add Layer Mask:

Next, in the options that appear, we choose the Selection option and hit Add:

This creates a mask that limits edits to only the selected part of the image. Now, with the layer thumbnail (not the mask) active, we go to Colors > Hue-Saturation or Colors > Colorize to apply a color change. The mask ensures that the adjustment only affects the specific region we selected earlier.

If the effect spills over too much or misses spots, we can fine-tune the mask. By clicking on the mask thumbnail, we can paint directly on it using a brush: black to hide, white to reveal, and gray for soft blending. This gives us full control over exactly where the new color appears.

Finally, we check our results by toggling the visibility of the original layer. Once we’re happy with the outcome, we can merge the layers or export the image as needed.

5. Conclusion

In this article, we explored three different ways to swap colors in GIMP.

First, we can use the Color Exchange tool, which is quick and works best for simple, solid colors. Next, the By Color Select tool, combined with Colorize or Hue-Saturation, gives us more control and preserves texture, making it ideal for photos. Finally, Layer Masks offer the most flexibility, allowing us to make detailed edits.

The post How Can I Swap Colors With GIMP? first appeared on Baeldung on Linux.

     

Related Stories

• Linux File Editing Series
• Compare Two Images in Linux
• Software Alternatives for Utilizing Digital Pens on Linux

 

1. Introduction

In Linux, package managers handle software installation, updates, and dependency management. Each distribution typically includes a default package manager:

• Debian and its derivatives often use apt
• RHEL and similar distributions commonly use dnf or yum
• Arch uses pacman
• SUSE-based systems use zypper

In this tutorial, we’ll discuss how to identify the package manager used by a given Linux distribution. In scripting, automation, or multi-distro environments, selecting the correct package manager can improve efficiency and reduce the chance of errors.

2. Identifying Package Manager by Distribution Name

One method to identify the package manager of a system involves checking the distribution name. Since each major Linux distribution comes with a default package manager, identifying the distribution often indicates which package manager is in use.

One way to check the distribution is the /etc/os-release script:

$ source /etc/os-release && echo $NAME
Ubuntu

Alternatively, the lsb_release command should show the name of the distribution:

$ lsb_release -i | cut -f2
Ubuntu

In this case, we extract the second whitespace-separated field.

With this information, it could be easier to determine the default package manager via a list similar to the one we saw earlier.

In this case, the output shows that the distro is Ubuntu. As already outlined, apt is the default package manager for Ubuntu. To verify that apt is installed, we can use the which command:

$ which apt
/usr/bin/apt

If the output shows a file path like /usr/bin/apt or similar, apt is installed in the current system and distribution.

If not, it likely isn’t installed. Of course, a system can use different package managers.

3. Identifying Package Managers With a Bash Script

For a quick and automated way to identify the package manager, we can use a Bash script that checks for common package managers.

3.1. Basic Script for a Single Package Manager

Let’s create the script:

$ cat pkgmgrid.sh
if command -v apt > /dev/null 2>&1; then
    echo "apt package manager"
elif command -v dnf > /dev/null 2>&1; then
    echo "dnf package manager"
elif command -v yum > /dev/null 2>&1; then
    echo "yum package manager"
elif command -v zypper > /dev/null 2>&1; then
    echo "zypper package manager"
elif command -v pacman > /dev/null 2>&1; then
    echo "pacman package manager"
else
    echo "No known package manager found"
fi

Now, we make the script executable and run it:

$ chmod +x pkgmgrid.sh
$ ./pkgmgrid.sh
apt package manager

Yet, this script detects only one package manager, even if multiple are installed. It uses the chain of if–elif statements, which means that once it meets a condition, it skips the other options. For example, if Ubuntu has both apt and snap installed, the script identifies only the first one it matches and ignores the others.

3.2. Advanced Script for Multiple Package Managers

However, some distributions support more than one package manager. For instance, Debian uses both the high-level apt and low-level dpkg. Similarly, Fedora uses dnf and rpm. Additionally, some systems support universal package managers such as snap and flatpak for cross-distribution compatibility.

For systems with more than one package manager, we can use a more flexible script. This script uses the for loop to iterate through a list of some common package managers, checking each one without stopping at the first match. This way, it detects more than one installed package manager. It also detects the Linux distribution and identifies the default package manager based on the detected distro.

Let’s create the script:

$ cat package-manager-id.sh
#!/bin/bash
# Detect installed package managers
package_managers=("apt" "yum" "dnf" "zypper" "pacman" "snap" "flatpak")
echo "Installed package managers on this Linux system:"
for manager in "${package_managers[@]}"; do
    if command -v "$manager" > /dev/null 2>&1; then
        echo "-$manager"
    fi
done
# Detect distro
if [[ -f /etc/os-release ]]; then
    distro=$(source /etc/os-release && echo $NAME)
else
    distro="*Unknown*"
fi
echo "Detected distro: $distro"
# Default package manager, if any
echo -n "Default distro package manager: "
if [[ "$distro" == "Ubuntu" || "$distro" == "Debian" || "$distro" == "Linux Mint" ]]; then
    echo "apt"
elif [[ "$distro" == "Fedora" || "$distro" == "Red Hat"* ]]; then
   echo "dnf"
elif [[ "$distro" == "CentOS" ]]; then
   echo "yum"
elif [[ "$distro" == "Arch Linux" || "$distro" == "Manjaro" ]]; then
    echo "pacman"
elif [[ "$distro" == "openSUSE" ]]; then
    echo "zypper"
fi

Now, we make the script executable and run it:

$ chmod +x package-manager-id.sh
$ ./package-manager-id.sh
Installed package managers on this Linux system:
-apt
-snap
Detected distro: Ubuntu
Default package manager: apt

The output confirms that the system has both the apt and snap package managers installed, with apt expected to serve as the default package manager.

4. Conclusion

In this article, we’ve covered how to identify the package manager of a Linux distribution. We explored methods using system files, commands, and Bash scripts to detect both installed and default package managers. Knowing which package manager the system uses helps make installing, updating, and running scripts easier and more reliable across different Linux systems.

The post How to Identify the Package Manager of a Linux System first appeared on Baeldung on Linux.

     

Related Stories

• How to Check for Available Package Updates in Linux
• How to Properly Install Valgrind?
• Background Jobs in a Loop in Bash

 

1. Introduction

When we write Bash scripts, we often need to perform repetitive tasks, such as processing files, making requests, or handling data in a loop. The tasks may be time-consuming, and executing them one by one slows down the process. We can execute each iteration as a background process. This way, we don’t wait for one task to finish before starting the next. But while this looks simple at first, backgrounding inside loops comes with its own set of challenges.

Background jobs can overwhelm the system or create processes that are difficult to control if left unchecked. We should therefore be careful of job limits, handle cleanup correctly, and ensure the script waits for all jobs to complete.

In this tutorial, we’ll discuss several patterns for running background jobs in loops. We’ll also have a quick mention of alternatives like xargs and parallel.

2. Basics of Backgrounding in Bash

Backgrounding commands allows us to move on without waiting for each command to complete. We background a command in Bash using the & operator. It’s handy when we need to execute lots of tasks simultaneously, particularly in loops. There is nothing extra to install in the system. As long as we have Bash installed (typically by default on most Linux distros), we are set.

Let’s take a brief look at an example Bash script to understand how backgrounding works:

#!/bin/bash
sleep 5 & echo "Waiting for the background job..."
wait
echo "Done"

Here we run the sleep 5 command in the background using &. Then we immediately print a message while the sleep command runs in the background. The wait command makes the script wait for the background process to finish. Finally, when everything is finished, we print “Done.” This is the foundation of more advanced job control, which we’ll look at next.

3. Naive Backgrounding in a Loop

One of the simplest ways to run multiple tasks at once in Bash is to send a command to the background using & within a loop. This makes it easy to start many tasks without waiting for each one to finish. It’s easy to write and is acceptable for small scripts. Let’s see a simple example:

#!/bin/bash
for i in {1..5}; do
  echo "Processing item $i" &
done
wait
echo "All background jobs finished."

In here, we’ve got a for loop echoing messages for items 1 through 5. Each of the echo statements runs in the background using &, so the loop doesn’t wait. The wait command instructs the script to wait until all background jobs finish before echoing the last message.

This is an efficient way to parallelize tasks, but it has a risk. If the command in the loop is resource-intensive, launching too many background jobs at once can overwhelm the system. We’ll look at a better means of handling this in subsequent sections.

4. Controlled Parallelism With wait

Background jobs in a loop are fast, but launching too many can overwhelm the system. To alleviate that, we control how many jobs run in parallel. Bash has the wait and wait -n features to control background jobs nicely without external utility assistance.

We don’t have to install anything for this, as wait is included in Bash. To use wait -n, though, we need Bash 5 or newer. To install or upgrade Bash on most Linux distributions:

$sudo apt-get install bash

Let’s see a basic example where we control the number of background jobs in a loop:

#!/bin/bash
max_jobs=3
for i in {1..10}; do
  echo "Starting job $i" &
  while (( $(jobs -r | wc -l) >= max_jobs )); do
    wait -n
  done
done
wait
echo "All jobs completed."

Here we have max_jobs = 3, so up to three background jobs are run concurrently. Inside the for loop, we start a job in the background using &. Then we find out how many jobs are running by using jobs -r piped to wc -l. If the active jobs reach the limit, we use wait -n, which waits for any one of them to finish before running another. This technique gives us easy but excellent control over concurrency among jobs, keeping it silky and safe.

6. Using GNU Parallel or xargs -P as Alternatives

Instead of using background jobs and manually creating a loop to control them, we can use xargs -P or GNU Parallel. Both simplify parallel execution and let us specify how many jobs run simultaneously. They create job control internally, which simplifies our scripts. At first, let’s start by installing these tools:

$ sudo apt-get install parallel findutils

Now, let’s start with a basic example using xargs:

$ seq 1 10 | xargs -n 1 -P 3 -I{} echo "Processing item {}"

In this command, seq 1 10 outputs numbers 1 to 10. We pipe it to xargs, which runs the echo command for each number. The -n 1 option tells xargs to use a single item per command, -P 3 sets the number of parallel jobs to 3, and -I{} specifies a placeholder. So, three echo commands run in parallel. As soon as any job finishes, another starts. Now let’s try the same thing with GNU Parallel:

$ seq 1 10 | parallel -j 3 echo "Processing item {}"

In this, parallel reads from seq 1 10 and runs the echo command on them. The -j 3 option does three jobs at one time. {} is a wildcard, like xargs.

Parallel has additional features than xargs—like better handling of output and multi-core awareness—so it’s better for more complex jobs. Both facilities enable us to keep things clean and efficient without the need to write special job control code. In handling large amounts of input or big commands, they can avoid time wastage and system crashes.

7. Cleanup and Error Handling

When running background jobs in Bash, we have to be careful about cleaning up the processes we start. If our script is ended prematurely or interrupted, we may leave behind orphaned jobs. To avoid this, we utilize the trap command. It lets us trap signals like SIGINT or EXIT and run custom commands if something goes wrong or the script ends.
Here’s a basic example showing how we can use trap to clean up running background jobs:

cleanup() {
  echo "Cleaning up..."
  jobs -p | xargs -r kill
}
trap cleanup SIGINT SIGTERM EXIT
for i in {1..5}; do
  sleep 60 &
done
wait

In this script, we define a cleanup function that kills all running background jobs using jobs -p and xargs kill. Then we use trap to connect this function to signals like SIGINT (Ctrl+C), SIGTERM, and EXIT. This way, if the script is stopped manually or crashes, it’ll still clean up the background jobs. Finally, we run five background sleep commands and use wait to let them finish. This pattern keeps our scripts safe and avoids leaving stray processes behind.

8. Conclusion

In this article, we’ve shown that running background jobs in a loop under Bash isn’t just about adding &. Without proper control, it can overwhelm the system. Using wait helps manage this, and wait -n offers better control by reacting as jobs finish.

We also covered tools like xargs -P and parallel for cleaner parallel execution. For real-world scripts, it’s essential to handle cleanup, set job limits, and manage failures. Bash’s built-in tools like trap and jobs make this possible without extra dependencies. These techniques make batch processing faster, safer, and more scalable.

The post Background Jobs in a Loop in Bash first appeared on Baeldung on Linux.

     

Related Stories

• Executing Commands in Gnuplot through Shell Script
• Converting Output to String in Linux
• How to Identify the Package Manager of a Linux System

 

1. Overview

Most Linux system commands are built around a simple flow: the command reads from the standard input and writes to the standard output. This arrangement is very rudimentary but also extremely flexible when combined with input-output redirection. As a result, we can perform arbitrary operations on files.

In this tutorial, we’ll learn how to perform input-output redirection within a C program.

2. Linux Redirection Basics

In the Linux command line, two operators govern redirection: < for input and > for output.

For instance, let’s consider the cat command. It reads input and prints it on the screen when Return is encountered:

$ cat
This line will be repeated
This line will be repeated
^C

If we want to send input to a file, we can redirect the output:

$ cat > output_file
It will go to the file

Now, let’s redirect output_file to the input of cat, which means cat should print it in the terminal:

$ cat < output_file
It will go to the file

Thus, we populate a file through standard input and produce its contents via standard output.

3. C File Descriptors

With C, we access files using file descriptors. For a secondary storage file, we can obtain a descriptor with the open system call. The descriptor is an integer variable, set by open to the lowest available value. A function that operates on file descriptors uses them to find the file metadata, complete information about the corresponding file or device.

We use special, predefined values for standard streams:

• standard input (STDIN): 0 (zero)
• standard output (STDOUT): 1 (one)
• standard error (STDERR): 2 (two)

Armed with this basic information, we should be ready to understand file descriptor duplication.

4. The dup2() Function

The dup2() function duplicates a file descriptor:

int dup2(int oldfd, int newfd)

When the function returns, newfd refers to the file or device indicated by oldfd before. Consequently, the file pointed to by oldfd is closed. So, if the old file descriptor points to standard output and the new one to a file, the file should now act as the standard output. Any C function or Linux command called inside a C program and designed to write to STDOUT should now output to that file.

Critically, we achieve this duplication and redirection without any modification to the function code.

Finally, dup2() returns the new file descriptor on success and -1 on failure.

5. Examples

Let’s examine a few examples to get familiar with the dup2() function. For the sake of simplicity and clarity, we skip error checking after function calls.

5.1. Redirecting to File

In this first program, example_1.c, we redirect the printf command output to the user-provided file:

#include <stdlib.h>   /* for exit */
#include <stdio.h>    /* for printf and stderr */
#include <fcntl.h>    /* for open */
#include <unistd.h>   /* for dup2 */
#define STDOUT 1
int main(int argc, char **argv)
{
    int file_desc;
    char *output_file_name;
    if (argc != 2)
    {
        fprintf(stderr, "Provide output filename, correct use: %s output_file\n", argv[0]);
        exit(EXIT_FAILURE);
    }
    output_file_name = argv[1];
    file_desc = open(output_file_name,
                O_CREAT | O_TRUNC | O_WRONLY, /* create, trunc, only write to */
                S_IRUSR | S_IWUSR);           /* user can read and write, if newly created */
    printf("Printing to standard output before redirection \n");
    printf("Switching standard output to file \"%s\".\n", output_file_name);
    dup2(file_desc, STDOUT); 
    printf("Printing to standard output after redirection.\n");
    exit(EXIT_SUCCESS);
}

In this case, the output filename comes from the command line, stored in argv[1]. Then, we create or open the corresponding file, saving its descriptor in the file_desc variable. Finally, with the dup2() call, we replace STDOUT with this variable.

Let’s compile the program:

$ gcc example_1.c

Then, we run it, using the default program name, a.out:

$ ./a.out test_output_file
Printing to standard output before redirection 
Switching standard output to file "test_output_file".

Finally, let’s check the output file:

$ cat test_output_file
Printing to standard output after redirection.

As expected, we see that the specified file contains the expected data.

5.2. Overwriting Current Process

In the next example, we start the uname command to provide the system name and details. Let’s study example_2.c code:

#include <stdlib.h>   /* for exit */
#include <stdio.h>    /* for printf and stderr */
#include <fcntl.h>    /* for open */
#include <unistd.h>   /* for dup2 */
#define STDOUT 1
int main(int argc, char **argv)
{
    int file_desc;
    char *output_file_name;
    char *cmd[] = { "/usr/bin/uname", "-a", 0 };
    if (argc != 2)
    {
        fprintf(stderr, "Provide output filename, correct use: %s output_file\n", argv[0]);
        exit(EXIT_FAILURE);
    }
    output_file_name = argv[1];
    file_desc = open(output_file_name,
                O_CREAT | O_TRUNC | O_WRONLY, /* create, trunc, only write to */
                S_IRUSR | S_IWUSR);           /* user can read and write, if newly created */
    printf("Output of command %s will be redirected to file \"%s\"\n", cmd[0], output_file_name);
    dup2(file_desc, STDOUT);
    execvp(cmd[0], cmd);
    exit(EXIT_FAILURE);    /* get here only if error in execvp */
}

First, we provide a Linux shell command with arguments as an array of strings in the cmd variable. Then, we create a file and substitute the standard output with it. Afterward, we start the uname command using the execvp() function. Thus, the command should run in a new process, an image of the current one. So, the output substitution holds for this process too.

Now, let’s compile the program:

$ gcc example_1.c

Afterward, we can start it and examine the result:

$ ./a.out test_output_file
Output of command /usr/bin/uname will be redirected to file "test_output_file"
$ cat test_output_file
Linux ubuntu 6.8.0-59-generic #61~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Tue Apr 15 17:03:15 UTC 2 x86_64 x86_64 x86_64 GNU/Linux

Of course, the redirection works in this case as well.

5.3. Child Process for Redirection

The successful call of execvp() ends the current process. Now, we want to preserve the current process, so we use the fork() function to create a child process.

#include <stdlib.h>   /* for exit */
#include <stdio.h>    /* for printf and stderr */
#include <fcntl.h>    /* for open */
#include <unistd.h>   /* for dup2 */
#include <sys/wait.h> /* for wait */
#define STDOUT 1
/* child process function prototype */
void run_cmd(int fd, char **cmd);
int main(int argc, char **argv)
{
    int file_desc;
    char *output_file_name;
    char *cmd[] = { "/usr/bin/uname", "-a", 0 };
    if (argc != 2)
    {
        fprintf(stderr, "Provide output filename, correct use: %s output_file\n", argv[0]);
        exit(EXIT_FAILURE);
    }
    output_file_name = argv[1];
    file_desc = open(output_file_name,
                O_CREAT | O_TRUNC | O_WRONLY, /* create, trunc, only write to */
                S_IRUSR | S_IWUSR);           /* user can read and write, if newly created */
    run_cmd(file_desc, cmd);
    printf("We're finished!\n");
    exit(EXIT_SUCCESS);
}
/* Function to fork and execute in a new thread */
void run_cmd(int fd, char **cmd)
{
    int status; 
    switch (fork()) {
    case 0:    /* child process */
        dup2(fd, STDOUT);
        execvp(cmd[0], cmd);
        exit(EXIT_FAILURE);    /* get here only if error in execvp */
    default: /* parent process */
        while (wait(&status) != -1) ;    /* wait for child to be finished */
        printf("Child process finished\n");
        break;
    case -1: /* fork error, skip handling it */
    }
    return;
}

The run_cmd function creates a new process with fork() and takes appropriate action according to its result. Notably, the code of the run_cmd function is executed in both the child and the parent processes. The return value of fork() is zero, indicating the child process. In this case, we start a new process with changed file descriptors, as in the last example. In the parent process, we wait for the child with the wait() system call.

Let’s compile and test the program:

$ gcc example_3.c
$ ./a.out test_output_file
Child process finished

We can see that the file descriptor duplication has a process scope. The child dup2() call doesn’t affect the parent’s standard output, and the Child process finished message appears in the terminal.

6. Restoring Standard Output

Now that we’ve gotten to know different redirections, let’s revisit the first example and switch back the standard output to the terminal. Let’s check example_4.c:

#include <stdlib.h>   /* for exit */
#include <stdio.h>    /* for printf and stderr */
#include <fcntl.h>    /* for open */
#include <unistd.h>   /* for dup2 */
#define STDOUT 1
int main(int argc, char **argv)
{
    int file_desc;
    char *output_file_name;
    if (argc != 2)
    {
        fprintf(stderr, "Provide output filename, correct use: %s output_file\n", argv[0]);
        exit(EXIT_FAILURE);
    }
    output_file_name = argv[1];
    file_desc = open(output_file_name,
                O_CREAT | O_TRUNC | O_WRONLY, /* create, trunc, only write to */
                S_IRUSR | S_IWUSR);       /* user can read and write, if newly created */
    printf("Printing to standard output before redirection \n");
    fflush(stdout);
    int saved_stdout = dup(STDOUT); /* save standard output description for later */
    printf("Switching standard output to file \"%s\".\n", output_file_name);
    dup2(file_desc, STDOUT); 
    printf("Printing to standard output after redirection.\n");
    dup2(saved_stdout, STDOUT); /* copy saved STDOUT to the current one. Ovewrite previous redirection */
    printf("The standard output is terminal again!\n");
    exit(EXIT_SUCCESS);
}

We use dup(), a sister function of dup2(). This function creates a copy of the file description and enables both files to be operated on simultaneously. Finally, we use dup2() to switch STDOUT back to standard output.

Let’s verify the result:

$ gcc example_1a.c
$ ./a.out test_output_file
Printing to standard output before redirection 
Switching standard output to file "test_output_file".
The standard output is terminal again!

This way, we can restore the original STDOUT.

7. Conclusion

In this article, we learned about output redirection in C.

First, we recalled Linux redirection basics. Then, we took a brief look at how C programs dealt with file descriptors and introduced the dup2() function. Later, we moved to examples of the output redirection in C, substituting a file for the standard output and even redirecting the output of the Linux command uname called from inside the C program.

The post Redirecting Standard Output in C With the dup2() Function first appeared on Baeldung on Linux.

     

Related Stories

• How to Find the SCHED_RR Scheduling Policy’s Time Slice
• Which Process Sets $USER and $USERNAME
• Starting a Process on a Different TTY

 

1. Overview

A Linux system can become unbootable due to misconfigurations, broken packages, or accidental deletions. While a live distro on USB or CD/DVD is typically the recommended recovery support, physical access or compatible media isn’t always available. In these situations, booting directly into a shell with the command init=/bin/bash provides just enough access to fix critical problems, assuming the bootloader and kernel still work.

In this tutorial, we’ll learn how to apply this technique to a modern, encrypted Linux installation with LVM+LUKS. We’ll use Linux Mint 22 for our tests, but the information applies to any Debian/Ubuntu-based system.

2. How and Why to Use init=/bin/bash

In most modern Linux distributions, systemd is the first user-space process during the boot process. It runs with Process ID (PID) 1 and is responsible for launching and managing all other processes in the system:

$ ps -p 1
PID TTY          TIME CMD
  1 ?        00:00:03 systemd

In the GRUB menu, let’s press e to edit the commands before booting. Adding init=/bin/bash to the kernel parameters skips the usual startup and launches a Bash shell with PID 1. Optionally, we can remove quiet and splash. Then, let’s press F10 to boot. If the disk uses LUKS and LVM, the unlock prompt appears automatically.

This video shows the full process, with an arrow to highlight where to pay attention:

The system is now in an emergency recovery state with root privileges, and /bin/bash has the PID 1:

# ps -p 1
PID TTY          TIME CMD
  1 ?        00:00:00 bash

This allows us to bypass broken service managers, login daemons, and most boot-time scripts. We can use this approach as a last resort when misconfigurations or errors prevent a normal boot.

3. Resetting the root Password

We can use the init=/bin/bash emergency shell to reset passwords.

First, we need to remount the file system as read/write because it’s read-only by default:

# mount | grep " / "
/dev/mapper/vgmint-root on / type ext4 (ro,relatime)
# mount -o remount,rw /
[...] EXT4-fs (dm-1): re-mounted [...] r/w. Quota mode: none.
# mount | grep " / "
/dev/mapper/vgmint-root on / type ext4 (rw,relatime,errors=remount-ro)

Then, we can change the password for the root or any other user:

# passwd root
[...]
passwd: password updated successfully

Standard commands like poweroff, reboot, or shutdown don’t seem to work because the standard init system isn’t running:

# reboot
System has not been booted with systemd as init system (PID 1). Can't operate.

Usually, the -f flag solves the problem:

# reboot -f

In rare cases, this isn’t sufficient, so we need a different approach. First, we have to flush any pending disk writes by running sync, and then write b to the file /proc/sysrq-trigger:

# sync
# echo b > /proc/sysrq-trigger

This method only makes sense in an emergency environment, as it forces an immediate reboot without first unmounting file systems or stopping services properly. In a production environment, this can result in data loss or corruption.

4. Recovering a Broken Linux Installation

Here we’ll try to identify and resolve some issues preventing our Linux machine from booting.

4.1. Fix Disk Errors Preventing Booting

Unexpected power outages can leave a Linux system inoperable upon reboot. This includes virtual private servers, where abrupt reboots during cloud provider maintenance can leave guest operating systems with corrupted file systems.

The video below shows a similar failure. We corrupted the file system on purpose and disabled every automatic repair to see what would happen if fsck couldn’t fix the damage on its own. This is a rare but real situation:

In this scenario, using only init=/bin/bash isn’t ideal because the kernel will still attempt to mount the corrupted root file system. However, adding break=premount gives us the BusyBox’s emergency shell without mounting any file system. It runs entirely from the initramfs in RAM:

BusyBox offers a variety of essential recovery commands, such as fsck, cryptsetup, and lvm. However, the list of commands in the man page is incomplete.

In BusyBox, let’s manually mount LVM and fix any errors in the file system. Of course, we must be careful to adapt these example commands to our configuration:

(initramfs) cryptsetup open --type luks /dev/sda3 cryptroot
Enter passphrase for /dev/sda3: 
 
(initramfs) lvm vgchange -ay
  2 logical volume(s) in volume group "vgmint" now active
 
(initramfs) fsck.ext4 -f /dev/mapper/vgmint-root
e2fsck 1.47.0 (5-Feb-2023)
/dev/mapper/vgmint-root: recovering journal
Clearing orphaned inode 264824 (uid=0, gid=0, mode=0100600, size=2)
Clearing orphaned inode 264849 (uid=0, gid=0, mode=0100644, size=1131)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Free blocks count wrong (3456692, counted=3456674).
Fix<y>? yes
Free inodes count wrong (901506, counted=901501).
Fix<y>? yes
/dev/mapper/vgmint-root: ***** FILE SYSTEM WAS MODIFIED *****
/dev/mapper/vgmint-root: 469379/1370880 files (0.1% non-contiguous), 2022750/5479424 blocks
 
(initramfs) reboot -f

This way, Linux reboots smoothly without disk errors.

Alternatively, instead of rebooting, we can type exit to quit BusyBox and start /bin/bash to perform additional recovery operations.

4.2. Internet Connection to Reinstall Broken Packages

If essential packages are missing or damaged, the system can’t finish a normal boot. In this example, Linux fails to boot because /sbin/init is missing:

If we can boot with init=/bin/bash, then we can try to restore some critical packages.

Here is an example of how to manually set up an Internet connection to use the package manager. However, let’s keep in mind to adapt the commands to our network configuration:

# Remount root filesystem as read-write
# mount -o remount,rw /
# Show network interfaces
# ip link show
enp0s3: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN [...]
# Bring up the network interface
# ip link set enp0s3 up
[...] enp0s3 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX
# Request an IP address via DHCP (error may appear, safe to ignore)
# dhclient enp0s3
# Check assigned IP address
# ip -brief addr show enp0s3
enp0s3  UP  10.0.2.15/24 fe80::a00:27ff:fe95:27fd/64
# Confirm network interface configuration
# ifconfig
enp0s3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.0.2.15  netmask 255.255.255.0  broadcast 10.0.2.255
        [...]
# Mount proc filesystem
# mount -t proc none /proc
# Mount sysfs
# mount --rbind /sys /sys
# Mount devfs
# mount --rbind /dev /dev
# Add default route (may already exist)
# ip route add default via 10.0.2.2 dev enp0s3
# Show current routing table
# ip route
default via 10.0.2.2 dev enp0s3
10.0.2.0/24 dev enp0s3 proto kernel scope link src 10.0.2.15
# Set DNS resolver manually
# echo "nameserver 1.1.1.1" > /etc/resolv.conf
# Test internet connectivity
# ping -c 1 baeldung.com
PING baeldung.com (172.66.40.248) 56(84) bytes of data.
64 bytes from 172.66.40.248: icmp_seq=1 ttl=255 time=52.8 ms
--- baeldung.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms

We’re now ready to reinstall some essential packages:

• systemd + systemd-sysv: provide /sbin/init and start every other service
• libc6: the GNU C runtime; almost every binary on the disk links to it
• libpam-modules + libpam-modules-bin: vital for login, su, sudo, and graphical display managers
• initramfs-tools: builds the initramfs image that the bootloader hands to the kernel
• linux-image-generic: meta-package for the current kernel image and headers

Let’s try to reinstall them:

# dpkg --configure -a
# apt update
# apt install --reinstall systemd systemd-sysv libc6 \
    libpam-modules libpam-modules-bin initramfs-tools linux-image-generic \
    libpam0g libpam-runtime
# update-initramfs -c -k all
# dpkg --configure -a

We can install as many other packages as we want.

At this stage, we can manually edit configuration files such as /etc/fstab, /etc/crypttab, and /etc/shadow. We can also remove problematic drivers or modules and perform other administrative tasks to fix a system that won’t boot up.

Finally, let’s run reboot -f to make Linux reboot smoothly.

5. Conclusion

In this article, we examined how to use the init=/bin/bash kernel parameter and the break=premount fallback to access a minimalist root shell on systems that wouldn’t otherwise boot.

This root environment enables us to unlock LUKS volumes, activate LVM, remount the root file system for reading and writing, reset forgotten passwords, and repair corrupted file systems using fsck. We can also reinstall core packages after setting up the network manually and carry out various configuration fixes.

Mastering these low-level recovery techniques can transform seemingly catastrophic “won’t boot” situations into solvable problems. However, it’s always important to maintain an up-to-date backup for disaster recovery purposes.

The post Linux Emergency Recovery With init=/bin/bash first appeared on Baeldung on Linux.

     

Related Stories

• Linux Emergency Recovery With init=/bin/bash - Enclosure
• How to Restore Systemd After Deleting It Accidentally
• How to Dual Boot Windows and Linux

 

1. Overview

We often rely on traditional security measures, such as strong passwords, permissions, and firewalls, to protect Linux systems. However, sometimes we need more fine-grained control, such as managing the possible actions of processes. That’s where SELinux (Security-Enhanced Linux) comes in.

Originally developed by the National Security Agency (NSA) of the USA and later released to the open-source community, SELinux enables sysadmins to define specific access policies to control how processes and users interact with system resources.

In this tutorial, we’ll explore what SELinux is, how it works, and why it matters.

2. What Exactly Is SELinux?

SELinux is a security module built into the Linux kernel to provide extra access control beyond the usual Unix-style permission system. It plays a key role in protecting against privilege escalation, misconfigurations, and zero-day exploits.

SELinux matters most in environments where security is crucial. Whether running web servers, databases, or containerized apps, SELinux can mean the difference between a contained threat and a full system compromise.

To truly appreciate SELinux, it’s wise to understand how it differs from the standard Linux security models.

2.1. The Problem With Traditional Permissions (DAC)

In Linux, Discretionary Access Control (DAC) is the “read-write-execute” permissions that control who can do what with a file. These provide the standard layer of security. Simply put, the owner of a file or process can decide who gets access.

While flexible, this can be a weak point. If a malicious program manages to get control, it might be able to use those discretionary permissions to escalate the damage.

For example, if a user owns a script, that user decides who can execute it. If a privileged user (like root) or a compromised process gains control, it can potentially access or modify any resource on the system. Traditionally, a root user can bypass DAC checks.

2.2. The Solution of Mandatory Access Control (MAC)

The big shift with SELinux is how it flips the way access control works. Most administrators and users are well aware of DAC, where file owners have a say. However, SELinux adds MAC to the kernel.

Under MAC, the operating system, rather than individual users, strictly enforces a system-wide security policy defined by the admin. Every single system call, every access attempt, gets checked against this policy.

What’s more, even the root user must comply. SELinux can limit root actions if they’re outside the defined policy. In other words, this is a much tighter security. We can stop unauthorized access or modifications to files, processes, and resources, even from a superuser account.

2.3. Default Deny Principle

The SELinux MAC approach relies on the default deny principle.

In short, if the SELinux rules don’t explicitly allow a specific action or access,  it’s automatically denied. This deny-by-default stance alone provides a great security advantage by reducing the attack surface.

2.4. How MAC and DAC Complete Each Other

SELinux doesn’t replace the basic file permissions that chmod or chown manage. Instead, it works alongside them in a specific order to provide deeper and mandatory control.

When a process tries to access a file, the system first checks DAC policy rules. Only if those basic permissions allow access, SELinux then steps in to evaluate its security policies (MAC).

This sequence means SELinux acts as a second checkpoint. This adds extra protection for scenarios where the DAC level might be too permissive, or when a compromised process manages to bypass it.

3. SELinux Core

A SELinux-enabled system relies on key security concepts to guide access decisions. Let’s see how these principles can improve Linux system security.

3.1. Security Context (Label)

SELinux assigns a security context (also called a security label) to every file, user, and process on the system. This context or label is a set of attributes that SELinux uses to determine access permissions. Simply put, these labels are name tags that tell what’s allowed and what’s not.

A security context consists of four parts (user:role:type:level). Let’s check what each one does:

• user: maps to one or more Linux users and defines which roles a user can assume, e.g., user_u or unconfined_u (not the same as the OS user)
• role: limits the actions certain users or types can perform, defining which types a user assigned to a role can access (SELinux assigns role names with the _r suffix, such as system_r)
• type: domain for processes and a type for files, which defines how processes and files interact with each other (all files and running processes are assigned a type ending in _t, for example, httpd_t for the web server process or var_t for files in /var)
• level (optional): range of clearance levels within Multi-Level Security (MLS) systems to set sensitivity levels, such as s0 or s1

Now, let’s run the ls -Z command on a directory with files to see some examples of what a security context may look like:

$ ls -Z
-rw-------. root root system_u:object_r:httpd_sys_content_t:s0 index.html
drwxrwxrwx. root root unconfined_u:object_r:admin_home_t:s0 backup

Here, the command lists file ownership (root) along with its rwx permissions. Moreover, the -Z switch includes the four parts of the security context of each entry (user, role, type, and security level), as in system_u:object_r:httpd_sys_content_t:s0.

3.2. Policy Rules

SELinux uses policy modules to define what each process can do. Every possible action (like process of type X reads file of type Y) needs an explicit rule allowing it, or else SELinux denies it. As we mentioned before, SELinux forbids everything by default unless we explicitly allow it.

For example, a policy rule might say “allow httpd_t processes to read httpd_sys_content_t files”. If we try an action not in the rules, SELinux blocks it and logs a denial.

To set a policy rule, we do so by following a basic syntax:

<rule_type> <subject> <object>:<object_class> <permission>;

Let’s break down what each part means:

• rule_type: action SELinux should take, usually allow, dontaudit, or neverallow
• subject: domain or type of the process requesting access
• object: type of the resource being accessed
• object_class: class of the object, like file, dir, tcp_socket
• permission: action being allowed, like read, write, open

For example, we can check a simple policy rule in action:

ALLOW apache_process apache_log:FILE READ;

This rule simply allows a process labeled apache_process to read a log file labeled apache_log.

3.3. Booleans

How about if we want to turn off a rule without editing the security policy?

An SELinux boolean is an on-off switch that enables changing how rules behave without rewriting an entire SELinux policy. For example, a common boolean is httpd_can_network_connect. By default, it might be off, so the web server (httpd_t) can’t make outbound network connections.

Let’s see how we can turn it on using the setsebool command:

$ setsebool -P httpd_can_network_connect on

By setting the above boolean to on, SELinux allows access without needing to tinker with policy files. Moreover, instead of using the on–off options, we can use their equivalent numerical values 0–1.

In fact, SELinux comes with many such booleans – for actions like allowing FTP write access, using NFS, and more – to adjust rules at runtime. We can list all the rules with getsebool -a:

$ getsebool -a | less
abrt_anon_write --> off
abrt_handle_event --> off
abrt_upload_watch_anon_write --> on
antivirus_can_scan_system --> off
antivirus_use_jit --> off
auditadm_exec_content --> on
authlogin_nsswitch_use_ldap --> off
authlogin_radius --> off
authlogin_yubikey --> off
awstats_purge_apache_log_files --> off
:

Here, the output can be quite long, so it’s best to pipe it to less to scroll through it page by page.

3.4. Modes

SELinux can run in three modes, each offering different levels of security control:

• enforcing (0): actively blocks violations
• permissive (1): logs violations without blocking
• disabled: turns off SELinux completely, with the system falling back to normal DAC permissions

We can check the current SELinux mode with getenforce:

$ getenforce
Enforcing

In this case, SELinux is in Enforcing mode.

Now, let’s use the setenforce mode to change it to Permissive:

$ setenforce 0

Here, the 0 is the MODE_ID for the Permissive mode. Conversely, 1 is the ID for Enforcing mode.

Notably, setenforce doesn’t persist after reboot. However, we can directly edit the SELinux config file (/etc/selinux/config) to make changes persist. Moreover, editing the config file is also how we can switch to Disabled mode.

4. Why Is SELinux Important?

It may seem that Linux file permissions (read, write, execute) and user ownership should be enough to keep a system secure. Of course, for simple setups, they usually are. However, once we run complex Internet-facing services, standard access permissions don’t cover every scenario.

A major advantage of SELinux is its ability to limit damage during security breaches.

Let’s say a web server (Apache httpd) is hacked. With traditional permissions, the attacker could read sensitive files in /etc, modify scripts in /var/www, and access user data.

Now, we can see a simple example of how SELinux can block access even for root users based on file labels.

First, we create a test file in the root user’s home directory:

$ echo "secret" > /root/zfile

Now let’s change the SELinux label of that file with the chcon command:

$ chcon -t admin_home_t /root/zfile

Here, we assign /root/zfile the type admin_home_t, which isn’t meant for web servers to access.

Finally, let’s check whether Apache can access the file:

$ runcon -t httpd_t -- cat /root/testfile
cat: /root/zfile: Permission denied

We use the runcon -t command to run cat /root/zfile under a different SELinux context (httpd_t), which is the domain Apache runs in. Even though cat runs as root, SELinux steps in and blocks it.

5. Conclusion

In this article, we explored what SELinux is, why it matters, and how it strengthens Linux security.

In particular, we looked at the way it works alongside traditional access permissions using labels, policies, and strict access rules. Through examples, we saw how SELinux can block unauthorized actions, even from superusers.

The post What Is SELinux? first appeared on Baeldung on Linux.

     

Related Stories

• Sending a Password via SSH or SCP Using subprocess.Popen in Linux
• Resolving the Reverse Tunnel Remote port forwarding failed for listen port SSH Error
• How to Fix USB Sticks Mounted as Read-Only

 

1. Introduction

As the ubiquitous method to facilitate and secure connections between remote systems, the Secure Shell (SSH) protocol supports multiple ways to handle point-to-point communication. Furthermore, one of the most useful features in this regard is remote port forwarding. In one of its basic forms, the latter enables going through Network Address Translation (NAT) filters and similar firewall restrictions.

In this tutorial, we talk about remote SSH port forwarding or reverse tunnels. First, we understand the problems that these features solve. Next, we go through the prerequisites and process of establishing a reverse tunnel. After that, we explore problems that might result from different aspects of SSH remote port forwarding, i.e., reverse tunnels.

We tested the code in this tutorial on Debian 12 (Bookworm) with GNU Bash 5.2.15. Unless otherwise specified, it should work in most POSIX-compliant environments.

2. Remote or Reverse Tunneling and Client Protection

To begin with, let’s understand the concept of remote or reverse tunneling. In essence, the idea is to use SSH from a protected client to establish a permanent tunnel to a remote server, enabling traffic in both directions.

There can be different kinds of client protection in this context:

• behind a router
• NAT
• firewall
• Virtual Private Network (VPN)

Basically, we can use this technique to gain access to the client side and manage any network resource that the client can control, all from a remote server that normally can’t directly connect to that client. In addition, local client ports can be forwarded to the remote server side.

This idea has two main names: remote tunneling and reverse tunneling, depending on the way it’s applied. In all cases, it provides port forwarding.

3. SSH Remote Port Forwarding

Remote port forwarding or reverse tunneling is a special case of remote tunneling, which exposes a local service or application to a remote server even when the local machine is protected in any of the ways mentioned earlier.

3.1. Requirements

To employ remote port forwarding with SSH, we need several prerequisites to be in place:

• SSH client on the client machine
• SSH server on the server machine
• network connectivity and visibility from client to server

In this case, we use xost as the server.

3.2. SSH Client -R Flag

When it comes to most SSH clients, the way to perform remote port forwarding is the -R flag, which takes a colon-separated list as its value. The latter contains four fields:

1. (optional, default localhost) remote_server_bind_address: address to use on the remote server for the reverse tunnel
2. remote_server_bind_port: port to use on the remote server for the reverse tunnel connection
3. client_network_host: address that the client has network access to
4. client_network_host_port: port at client_network_host

The SSH argument is the remote server that should be the opposite end of the tunnel.

In essence, connections to [remote_server_bind_address]:remote_server_bind_port on the remote server (provided as an argument) should be forwarded to the client network at client_network_host:local_port. Notably, both address-port combinations can be sockets instead. Without a remote_server_bind_address, connections only work for loopback interfaces, while an empty bind_address or * specifies all interfaces.

Notably, the -R flag is often used with -N to prevent any command from running and just establish the port forwarding (reverse tunnel) for future use.

3.3. Examples

To understand the idea of reverse tunnels, let’s see some examples.

First, we establish the basic template:

ssh -N -R [<remote_server_bind_address>]:<remote_server_bind_port>:<client_network_host>:<client_network_host_port> [<remote_server_user>@]<remote_server_address>

Now, let’s show a fairly simple case:

$ ssh -N -R localhost:8888:localhost:7777 uxer@xost

Here, any connection to the remote server xost on its localhost interface at port 8888 goes to the client that ran the command (second localhost) at port 7777.

Of course, the first localhost doesn’t need to be explicit, as it’s the default:

$ ssh -N -R 8888:localhost:7777 uxer@xost

This command should function in more or less the same way. Naturally, if we want to bind to another network interface on the remote server, we can do so via another address or a socket.

Lastly, when connecting to a client network machine (instead of locally to the client), we can specify the desired address and port in place of client_network_host:client_network_host_port:

$ ssh -N -R 8888:<client_network_host>:<client_network_host_port> uxer@xost

So, let’s do that:

$ ssh -N -R 8888:192.168.6.66:6666 uxer@xost

Thus, any connection to the loopback interface on xost at port 8888 goes to 192.168.6.66 at port 6666 in the client network.

4. Forwarding Port Issues

Different problems can arise during port forwarding and remote tunneling with SSH. Let’s explore some of them and see potential solutions.

4.1. Syntax Problems

It may take some time to understand the exact way each part of the -R flag value works. Considering this, we might end up mixing different addresses or ports, which can lead to unexpected errors and issues with accessibility.

For instance, if we use the remote_server_bind_address in the place of the client_network_host, we might see an error about an unknown host:

$ ssh -N -R 8888:xost:7777 uxer@xost
[...]
connect_to xost port 7777: failed

Furthermore, as with other networking tools, specifying exact parameters is paramount when constructing the SSH command for port forwarding. A missing or misplaced colon or bad ports and addresses can be hard to troubleshoot.

Another example involves the forced use of IPv6 addresses, which might need to be enclosed in square brackets.

To avoid such problems, checking the syntax and values multiple times is critical.

4.2. Privileged Ports

Reverse tunnels are a common occurrence within environments without root access.

To that end, attempting to use a port number below 1024 can result in permissions issues:

$ ssh -N -R 1000:xost:1100 uxer@xost
[...]
bind: Permission denied

The Permission denied error can be especially hard to diagnose when dealing with different machines, networks, passwords, and keys within the context of SSH. However, it usually just means that uxer is unable to bind port 1000 due to insufficient permissions.

Although the errors may be different, the remedy is the same: unless strictly necessary to do otherwise, it’s best to use port numbers above 1023.

4.3. Busy Ports

Commonly, when a forwarding fails, we see a fairly ambiguous error:

$ ssh -N -R *:8080:localhost:6666 uxer@xost
[...]
Warning: remote port forwarding failed for listen port 8080

Yet, one very common reason for issues when using reverse tunnels is a busy port.

In fact, checking whether a tunnel is up on the remote side might prove insightful even when there are no errors:

$ ss -tnlp | grep :8080
LISTEN 0      1            0.0.0.0:8080       0.0.0.0:*    users:(("nc",pid=10666,fd=3))

In this case, we see a netcat (nc) command uses the port we need for the tunnel. Thus, we can either stop that process or use a different port or IP version. However, the latter could happen unintentionally.

4.4. Wrong Internet Protocol (IP) Version

On top of the tunnel state, we can also see tunnel configurations by checking the remote server:

$ ss -tnlp | grep :8080
LISTEN 0      1            0.0.0.0:8080       0.0.0.0:*    users:(("nc",pid=10666,fd=3))                                 
LISTEN 0      128            [::1]:8080          [::]:*    users:(("sshd",pid=10667,fd=5))

In this case, both nc and sshd listen on 8080 after we’ve established a reverse tunnel without errors. However, sshd uses IP version 6 (IPv6), while nc works over IPv4 in this case. This might be desired behavior, but it could also be misleading when a successfully established tunnel is seemingly inaccessible through a given IP version.

4.5. Filtered Port

In specific cases, the remote_server_bind_port might end up being filtered. Let’s see what this may end up meaning for potential clients.

First, we establish a reverse tunnel:

$ ssh -N -R *:12345:localhost:6666 uxer@xost

Now, from another machine, we attempt to send a request to xost:12345:

$ curl xost:12345
curl: (7) Failed to connect to xost port 12345: Couldn't connect to server

At this point, we might doubt that the initial tunnel is working. However, it could be the case that port 12345 is inaccessible from outside the remote server xost. For example, we may need to configure a firewall or router. Yet, there are some ports that might even be filtered by the Internet Service Provider (ISP).

As already mentioned, reverse tunnels solve such filtering issues automatically on the client side for the client itself, but not beyond.

4.6. Remote SSH Server Configuration

One rare but possible reason for a reverse tunnel setup problem is an incorrect or unexpected configuration of the SSH server.

For instance, there are a couple of key settings for port forwarding:

• AllowTcpForwarding
• GatewayPorts

So, with the value of AllowTcpForwarding, we can enable (yes, default) or disable (no) TCP port forwarding, but we can also force only reverse and no local tunnels (remote) or only local instead of reverse tunnels (local) to be accepted.

On the other hand, GatewayPorts can be enabled (yes), disabled (no, default), or clientspecified. The latter enables the SSH client to specify the address. Since the default is no, ports usually only bind to 127.0.0.1 (loopback) on the remote host.

In case forwarding is disabled or a forbidden bind address is requested, we see the generic error:

$ ssh -N -R 0.0.0.0:8080:localhost:22 uxer@xost
[...]
Warning: remote port forwarding failed for listen port 8080

Still, if we know about these parameters, checking and correcting them in the sshd_config file (with a potential service restart) might solve some issues.

5. Summary

In this article, we talked about reverse SSH tunnels, i.e., SSH port forwarding, and issues that we might encounter when trying to use them.

In conclusion, although a reverse SSH tunnel is a fairly complex feature with many dependencies, by performing checks and diagnostics, we can deduce the correct reason for any failures and successfully set up stable forwarding.

The post Resolving the Reverse Tunnel Remote port forwarding failed for listen port SSH Error first appeared on Baeldung on Linux.

     

Related Stories

• Sending a Password via SSH or SCP Using subprocess.Popen in Linux
• What Is SELinux?
• Finding Out Why a Network Interface is Dropping Packets

 

1. Introduction

In Linux, Makefiles are powerful tools for automating build processes, but their syntax can sometimes be tricky, especially when it comes to conditional statements. The syntax differs significantly from traditional programming languages, leading to confusion and errors. A common issue is attempting to use if-else statements directly within recipe lines, which doesn’t work as expected.

In this tutorial, we’ll explore the syntax and examples of using if-else blocks in Makefiles.

2. Conditional Directives in Makefiles

We use several kinds of conditional directives in a Makefile:

• ifeq – tests if two strings are equal
• ifneq – tests if two strings aren’t equal
• ifdef – the code tests if the variable definition is available
• ifndef – the condition tests if a variable definition isn’t available

We’ll explore examples of the above conditionals in the subsequent sections.

3. Basic Syntax

Let’s take a look at the basic syntax for an if-else statement in a Makefile:

ifeq (condition)
    # Commands if condition is true
else
    # Commands if condition is false
endif

The above snippet is a basic skeleton on the conditional statements in a Makefile. We’ll explore the above directives using various examples.

3.1. Testing if Two Strings Are Equal

The ifeq directive tests if two strings are equal:

MODE = debug
ifeq ($(MODE),debug)
    CFLAGS = -g -O0 -DDEBUG
else
    CFLAGS = -O2
endif

In this example, if MODE equals “debug”, then CFLAGS takes on debugging flags; otherwise, it takes on optimization flags.

3.2. Testing if Two Strings Aren’t Equal

The ifneq directive tests if two strings aren’t equal to each other:

OS = linux
ifneq ($(OS),windows)
    RM = rm -f
else
    RM = del
endif

Here, if OS isn’t “windows”, the RM command takes the Unix version; otherwise, it takes the Windows command.

3.3. Testing if a Variable Is Defined

The ifdef directive tests whether or not a variable is defined:

ifdef DEBUG
    CFLAGS += -g -DDEBUG
endif

In this example, if DEBUG is defined (regardless of its value), the directive adds debugging flags to CFLAGS.

3.4. Testing if a Variable Isn’t Defined

The ifndef directive tests if a variable isn’t defined:

ifndef CC
    CC = gcc
endif

In this case, if the CC variable isn’t defined, the Makefile assigns “gcc” as its default value. We commonly use this pattern in Makefiles to provide default values that users can override.

4. Makefile Examples

In the following sections, we’ll explore examples that combine various aspects of the above conditionals into a Makefile.

4.1. Checking the Operating System

Here’s an example that demonstrates the usage of conditional statements for handling different operating systems:

# Define the default target
all: hello
# Check the operating system
ifeq ($(OS),Windows_NT)
    DETECTED_OS := Windows
else
    DETECTED_OS := $(shell uname -s)
endif
# Target that uses the detected OS
hello:
    @echo "Hello from $(DETECTED_OS)"
    @echo "This is a Make example"
# Conditional target behavior
ifeq ($(DETECTED_OS),Windows)
    install:
        @echo "Installing on Windows..."
else ifeq ($(DETECTED_OS),Darwin)
    install:
        @echo "Installing on macOS..."
else
    install:
        @echo "Installing on Linux or other OS..."
endif

In the above example, we initialize the the variable DETECTED_OS based on environment variable OS. The details of the above steps are:

• ifeq ($(OS),Windows_NT) checks if the environment variable OS equals “Windows_NT” (which is automatically set on Windows systems).
• If true, it sets DETECTED_OS to “Windows”.
• Otherwise, it runs the Unix command uname -s (which returns the kernel name) and assigns that output to DETECTED_OS.
• On macOS, uname -s returns “Darwin”; while on Linux, it returns “Linux”.

Subsequently, we use the variable DETECTED_OS for installing the appropriate software based on the operating system.

4.2. Conditional Expressions

If we need conditional logic within a recipe, we use shell conditionals:

check_file:
    @if [ -f "somefile.txt" ]; then \
        echo "File exists"; \
    else \
        echo "File does not exist"; \
    fi

Let’s break down the above code:

• check_file defines a target named “check_file”.
• @ at the beginning suppresses Make from printing the command before executing it (for cleaner output).
• if [ -f “somefile.txt” ]; then \ starts a shell conditional statement.
• echo “File exists”; prints “File exists” if the file exists.
• echo “File does not exist” prints “File does not exist” if the file doesn’t exist.

The entire command is actually a single shell command (a Bash if-statement). In a proper Makefile, this would typically be formatted with proper indentation for readability. In above example, we’re executing the command prefixed with @ in a Bash subshell.

4.3. Inline Conditionals

We can also use if conditionals for inline functions:

# Using $(if) function
MESSAGE := $(if $(DEBUG),Debugging mode, Release mode)
# Using computed variable names
MODE := debug
COMPILER_$(MODE) := gcc -g
COMPILER_release := gcc -O2
compile:
    @echo "Using compiler: $(COMPILER_$(MODE))"

The above example illustrates inline functions using $(if …) syntax:

• If the DEBUG variable is defined, the Makefile sets the MESSAGE variable to “Debugging mode”
• Set the MESSAGE variable to “Release mode” if variable DEBUG isn’t set

We also use a computed variable based on the value of the MODE variable. This allows us to initialize the appropriate compiler parameters and use it for compiling the program.

4.4. Using the shell Command

We can combine the shell command in Makefile to check the required disk space:

# define the minimum disk space required
MIN_SPACE_MB=1000
valid-env:
    @echo "validating build env ..."
ifeq ($(shell if [ $$(df -m . | tail -1 | awk '{print $$4}') -lt $(MIN_SPACE_MB) ];then echo 1; else echo 0; fi),1)
    $(error Insufficient disk space. At least $(MIN_SPACE_MB)MB required)
endif

The above example illustrates a complex example of checking the environment for available disk space. The steps are:

• Sset the MIN_SPACE_MB variable to “1000” assuming the required disk space is 1000 MB
• The command df -m . | tail -1 | awk ‘{print $$4} evaluates the disk space on the current file system
• Compare the output of the above command with the expected disk size (MIN_SPACE_MB) and echo the result of 0 or 1
• We compare the result with 1 to determine if disk space is available
• In case of error, the $(error …) block prints the error

One important idea of note is that in Makefiles, we can’t directly split a shell command across multiple lines. A separate shell instance typically executes every recipe. As a result, the variables defined in one line aren’t available in the next. This leads to variable scope limitations.

5. Conclusion

In this article, we learned various ways of using if-else blocks in a Makefile. Understanding conditional statements in Makefiles is essential for creating versatile and maintainable build systems. By properly implementing if-else logic in our Makefiles, we can ensure our build processes are robust and flexible across different platforms and configurations.

The post Using if-else Conditionals in a Makefile first appeared on Baeldung on Linux.

     

Related Stories

• Accessing a Defined struct in Another Source File in C
• How to Profile C++ Code Running on Linux
• How to Upload Many Images to Google Photos in Linux

 

1. Overview

We commonly use USB flash drives, also known as sticks, to transfer files, store backups, or create bootable media. As a Linux user, there are times we may encounter an issue where the USB stick mounts as read-only, preventing us from editing, copying, or deleting files. This might happen due to filesystem errors, hardware failure, improper unmounting, or permission issues.

In this tutorial, we’ll explain why USB sticks could mount as read-only, how to identify this as an issue, and ways to resolve it.

2. Why USB Sticks Mount as Read-Only

When we insert a USB stick into a Linux system, the kernel usually detects and mounts it automatically. Often, any desktop environment also enables quick access to the mount. In some cases, if something goes wrong in the process or the system detects any problems, it may mount the USB stick as read-only as the only option, or to prevent further damage.

In this section, we look at some of the most common causes for this.

2.1. Filesystem Errors

Linux relies on filesystem drivers and integrity checks to mount drives safely. If the kernel detects any problems, it may mount the USB stick as read-only to prevent further damage.

This often occurs when we haven’t properly ejected that USB stick in the past.

2.2. Mount Options

When the system or a user mounts the USB stick using the ro option, either manually or through /etc/fstab, the mount is read-only.

While this is an implicit configuration, it may be an unwanted side-effect of other processes.

2.3. Hardware Settings

Some USB sticks have a physical write-protect switch as a feature. When enabled, the storage hardware itself prevents any write operation.

The Linux kernel detects this flag and mounts the device in read-only mode.

2.4. Failing or Low-Quality USB Stick

When the memory of a USB stick starts to degrade, the internal controller may force the device into read-only mode to prevent data loss.

This is common for flash storage, as any failure there usually indicates further issues are imminent and, unlike some magnetic storage failures, flash burnouts are final.

3. How to Check if a USB Stick Is Mounted as Read-Only

To remedy an undesired read-only USB stick mount, we need to check whether that is indeed the case.

3.1. Using the mount Command

The mount command shows how the system currently mounts storage devices, including their mount options. We can use it to verify whether it has mounted the USB stick in read-only (ro) or read-write (rw) mode:

$ mount | grep /dev/sd
/dev/sdb5 on / type ext4 (rw,relatime,errors=remount-ro)
/dev/sdb5 on /var/snap/firefox/common/host-hunspell type ext4 (ro,noexec,noatime,errors=remount-ro)
/dev/sda1 on /mnt/MyUSB type exfat (ro,relatime,fmask=0022,dmask=0022,iocharset=utf8)

This command filters the list of mounted devices and only shows entries related to block storage, such as USB, solid state, and hard disk drives. In the output, /dev/sda1 represents the USB stick, which contains ro in its options, indicating that the system mounted it in read-only mode. On the same line, /mnt/MyUSB represents the mounting point.

3.2. Attempt USB Stick Write

To diagnose, we can try to create a file on the USB storage:

$ touch /mnt/MyUSB/contacts.txt
touch: cannot touch 'contacts.txt': Read-only file system

As expected, the output indicates the USB stick is mounted in read-only mode.

4. Fixing USB Read-Only Issues

Once we confirm the USB stick is mounted or always mounts as read-only, we can attempt to troubleshoot and resolve the issue.

4.1. Remount the USB Stick as Read-Write

Sometimes, a USB stick can be mounted as read-only by the system due to the default system behaviour, previous errors, or incorrect mount options that include the read-only (ro) flag. In such cases, we can try to remount the USB stick manually with write permissions.

First, we need to find the mount point:

$ df -h | grep /dev/sd
/dev/sdb5        73G   61G  8.1G  89% /
/dev/sda1       7.6G  6.6G  951M  88% /mnt/MyUSB

This output shows the USB stick /dev/sda1 is at /mnt/MyUSB.

Next, we remount the USB stick with the read-write flag:

$ sudo mount -o remount,rw /dev/sda1 /mnt/MyUSB

This command remounts /dev/sda1 with read-write permissions. To explain, the -o flag specifies mount options, while remount instructs the system to remount an already-mounted filesystem without unmounting it, and rw remounts the filesystem as read-write.

Finally, let’s verify if the system has remounted the USB stick with read-write permissions:

$ mount | grep /dev/sd
/dev/sdb5 on / type ext4 (rw,relatime,errors=remount-ro)
/dev/sdb5 on /var/snap/firefox/common/host-hunspell type ext4 (ro,noexec,noatime,errors=remount-ro)
/dev/sda1 on /mnt/MyUSB type exfat (rw,relatime,fmask=0022,dmask=0022,iocharset=utf8,errors=remount-ro)

From the output, we can see /dev/sda1 has an rw flag, indicating that the system successfully remounted the USB stick with read-write permissions.

4.2. Check for a Physical Write-Protect Switch

Some USB sticks, especially older ones, come with a physical write-protect switch that prevents data deletion or modification by locking the USB stick in read-only mode. When we enable the switch, we cannot write to the USB stick regardless of the operating system or permissions.

The switch is located on the side or bottom of the USB stick, and it signals the operating system to mount the device as read-only when enabled. However, in this state, we can view and copy files from the USB stick, but we can’t create, edit, or delete them.

To disable the write-protect switch, we usually need to remove the USB stick from the computer and toggle a switch to the side labeled unlock or rw.

Lastly, let’s test to see if we now have write permissions on the USB stick by attempting to create a file:

$ sudo touch /mnt/MyUSB/passwords.txt

If no errors occur and the file is created successfully, this means the read-only mode was probably due to the hardware write-protect switch.

4.3. Run Filesystem Check

Filesystem corruption often causes a USB stick to mount as read-only. This can occur if we remove the USB stick without unmounting it or if a power failure causes an interruption.

To fix filesystem errors, we use the fsck command.

First, we need to unmount the USB stick:

$ sudo umount /dev/sda1

Here, we replace /dev/sda1 with the name of the USB stick.

Next, let’s check the USB stick for filesystem corruption. Since we’re using an exFAT-formatted USB stick, we employ fsck.exfat:

$ sudo fsck.exfat /dev/sda1

The above command checks and attempts to repair any filesystem errors on /dev/sda1. In case of an error or prompt, we can follow the instructions to fix issues.

Once the scan completes without errors, we can remount the USB stick:

$ sudo mount /dev/sda1 /mnt/MyUSB

Here, we mount the /dev/sda1 filesystem to the /mnt/MyUSB directory, enabling us to access its contents from there.

Now, to verify whether the issue is resolved, we can try creating a file on the USB stick:

$ sudo touch /mnt/MyUSB/contacts.txt

In this example, /mnt/MyUSB represents the mounting point of the USB stick. If the file is created successfully, the USB stick is now writable. However, if the USB stick is still mounted as read-only, we can try the next solution.

4.4. Replace a Failing USB Stick

If none of the above solutions work and the USB stick still mounts as read-only, it could indicate hardware failure. USB flash memory supports a limited number of write cycles, and once it reaches this limit, controllers may switch the device to read-only mode to prevent data loss.

Let’s see some of the common signs of a failing USB stick:

• the system repeatedly mounts the USB stick as read-only
• the USB stick shows 0 bytes free even though it has space available
• the system no longer recognizes the USB stick
• when we try to perform file operations such as copy, delete, or create, we get input-output errors

In this case, the best option is to copy any available data off the USB stick and replace it with a more reliable one.

5. Conclusion

In this article, we discussed reasons why a USB stick may be mounted as read-only and how to identify and fix the issue.

By understanding the common causes of this issue, we can take the right steps to fix USB stick read-only issues.

The post How to Fix USB Sticks Mounted as Read-Only first appeared on Baeldung on Linux.

     

Related Stories

• SMB mount Security Modes and Fixing mount error(13): Permission denied in Linux
• What Is SELinux?
• Removing Log Files with a Cron Job in Linux