Month: April 2024

How to prevent hibernation and sleep on debian and proxmox laptops when the lid is closed

Posted on by soban

Virtualization servers based on Debian family systems, such as Proxmox, are often used in test environments where continuous availability is crucial. Sometimes these servers are installed on laptops, which serve as low-budget or portable solutions. However, the standard power management settings in laptops can lead to undesirable behaviors, such as sleeping or hibernating when the lid is closed. Below, I describe how to change these settings in an operating system based on Debian to ensure uninterrupted server operation.

Step 1: Accessing the Configuration File

Open the terminal and enter the following command to edit the /etc/systemd/logind.conf file using a text editor (e.g., nano):

Step 2: Modifying logind Settings

Find the line containing HandleLidSwitch and change its value to ignore. If the line is commented out (preceded by a # symbol), remove the #. You can also add this line to the end of the file if it does not exist.

Step 3: Applying and Restarting the Service

After making the changes and saving the file, you need to restart the systemd-logind service for the changes to take effect. Use the following command in the terminal:

With these changes, closing the laptop lid will no longer initiate hibernation or sleep, which is especially important when using Debian-based servers, including Proxmox, as server solutions.

Extending SWAP space on Proxmox using lvreduce

Posted on by soban

Introduction

Managing SWAP memory is a key element in administering Linux operating systems, especially in virtualization environments like Proxmox. SWAP acts as “virtual memory” that can be used when the system’s physical RAM is full. In this article, we will show how to increase SWAP space on a Proxmox server, using the lvresize tool to free up disk space that can then be allocated to SWAP.

Problem Overview

A user wants to increase SWAP space from 8 GB to 16 GB, but encounters the problem of lacking available space in the LVM volume group, which is required to increase SWAP.

Step 1: Checking Available Space

The command vgs displays the volume groups along with their sizes and available space.

Step 2: Reducing the Volume

Suppose there is a root volume of 457.26 GB, which can be reduced to free up an additional 8 GB for SWAP. Before reducing the volume, it is necessary to reduce the file system on this volume.

However, in the case of the XFS file system, reduction must occur offline or from a live CD.

Step 3: Using lvreduce

This command reduces the root volume by 8 GB, which is confirmed by a message about the volume size change.

Step 4: Deactivating SWAP

Before starting changes in SWAP size, SWAP must first be turned off using the above command.

Step 5: Expanding SWAP

The above commands first increase the SWAP space, then format it and reactivate it.

Finally, we verify the active SWAP areas using the above command to ensure everything is configured correctly.

This process shows how you can flexibly manage disk space on Proxmox servers, adjusting the size of SWAP depending on needs. Using lvreduce requires caution, as any operation on partitions and volumes carries the risk of data loss, therefore it is always recommended to make backups before proceeding with changes.

MySQL Troubleshooting – ErrorCode: 1114

Posted on by soban


Introduction

Working with MySQL, you may encounter various errors that can disrupt system operations. Error code 1114 is one of them and indicates a situation where the table the user is trying to write data to is full. This issue is particularly significant in the MySQL replication system, where its resolution is crucial for ensuring work continuity.

Problem Description

Error 1114 manifests itself with the message: “Could not execute Write_rows event on table docs; The table ‘docs’ is full”. This means that new rows cannot be written due to exceeding the size of the temporary table. The detailed error message might look like this:

Login to MySQL:

Change variable values:

After making these changes, all new connections to the MySQL server will use these updated values. You can verify them by performing:

Or

Now replication can be resumed and should work better. However, remember to modify the configuration so that after restarting MySQL these variables are set correctly. It may be necessary here to resume replication (if it was previously stopped):

If the problem has been resolved, at this stage checking the replication status:

Should not return any errors.

Modify the configuration file /etc/mysql/my.cnf:

Restart MySQL service:

Before restarting the service, it is recommended to execute SHUTDOWN; in the MySQL client.
Remember to resume replication.

Important Notes

  • System Resources: Ensure the server has sufficient RAM to handle the increased variable values.
  • Performance Monitoring: After making the changes, monitor performance to verify that the problem has been resolved.
  • Configuration Durability: Changes to the configuration file should be permanent to avoid resetting values after a restart.

Additional Verification Steps

  • Check Available Disk Space: The problem might also stem from lack of available disk space. This can be verified using the following command:

Summary

Resolving the issue associated with error code 1114 in MySQL replication requires understanding and adjusting the system configuration. The described steps show how increasing the size of the temporary table can prevent this error, enabling smooth operation of the replication system.

Automating the Backup Process in Proxmox: Practical Crontab Script and Configuration

Posted on by soban

In today’s world, where data is becoming increasingly valuable, proper backup management is crucial for the security of information systems. In this article, I present an effective way to automate the backup of key configuration files in Proxmox-based systems using a simple bash script and Crontab configuration.

Bash Script for Backup of the /etc Directory

The /etc file contains critical system configuration files that are essential for the proper functioning of the operating system and various applications. Loss or damage to these files can lead to serious problems. Below, I present an effective script, backup-etc.sh, that allows for the automated backup of this directory:

This script performs the following operations:

  1. Generates the current date and time, which are added to the name of the archive to easily identify individual copies.
  2. Uses the tar program with zstd compression to create an archived and compressed copy of the /etc directory.
  3. Removes archives older than 100 days from the /var/lib/vz/dump/ location, thus ensuring optimal disk space management.

Adding Script to Crontab

To automate the backup process, the script should be added to crontab. Below is a sample configuration that runs the script daily at 2:40 AM:

Redirecting output to /dev/null ensures that operations are performed quietly without generating additional output to standard output.

Download the Script from soban.pl

The backup-etc.sh script is also available for download from the soban.pl website. You can download it using the following wget command and immediately save it as /root/backup-etc.sh:

With this simple command, the script is downloaded from the server and granted appropriate executable permissions.

Benefits and Modifications

The backup-etc.sh script is flexible and can be easily modified to suit different systems. It is default placed in the /var/lib/vz/dump/ folder, which is a standard backup storage location in Proxmox environments. This simplifies backup management and can be easily integrated with existing backup solutions.

By keeping backups for 100 days, we ensure a balance between availability and disk space management. Old copies are automatically deleted, minimizing the risk of disk overflow and reducing data storage costs.

Summary

Automating backups using a bash script and Crontab is an effective method to secure critical system data. The backup-etc.sh script provides simplicity, flexibility, and efficiency, making it an excellent solution for Proxmox system administrators. I encourage you to adapt and modify this script according to your own needs to provide even better protection for your IT environment.