Troubleshooting “service glb getinfo: missing /etc/default/glbd” Error: A Comprehensive Guide #

We understand that encountering the error “/etc/init.d/glb: .: cannot open /etc/default/glbd: No such file” when attempting to run service glb getinfo can be a frustrating roadblock after what appears to be a successful Galera Load Balancer (GLB) installation. This specific error message indicates a critical misconfiguration, where the GLB service script cannot locate its essential configuration file. At revWhiteShadow, we specialize in dissecting these intricate technical challenges to provide you with actionable solutions that aim to outrank existing resources. Our goal is to offer a deeply detailed and authoritative guide that not only resolves your immediate problem but also solidifies your understanding of the GLB setup.

Understanding the Core of the “Missing Configuration File” Error #

The error message “/etc/init.d/glb: .: cannot open /etc/default/glbd: No such file” is fundamentally stating that the GLB initialization script (located in /etc/init.d/glb) is attempting to source (or read) configuration variables from a file expected to be at /etc/default/glbd. The operating system’s shell, when executing the GLB script, cannot find this specified file, leading to the script’s failure and the subsequent error.

The /etc/default/ directory is a standard location in many Linux distributions for storing default configuration settings for services. Scripts in /etc/init.d/ (or /etc/rc.d/init.d/ on some systems) often source files from this directory to load environment variables and parameters that dictate how a service should start, stop, and behave. In the context of GLB, /etc/default/glbd would typically contain parameters such as the IP addresses of the Galera nodes, port numbers, and other operational settings crucial for the load balancer to function correctly.

The absence of this file, even after a seemingly successful installation, points towards an incomplete or improperly configured installation process. It’s not uncommon for installation guides to sometimes overlook the creation or proper placement of these auxiliary configuration files, especially in more complex or niche software like GLB. Our aim is to provide a methodical approach to diagnose and rectify this specific issue, ensuring your GLB implementation is robust and operational.

Diagnosing the GLB Installation Environment #

Before we delve into specific solutions, it’s imperative to perform a thorough diagnostic sweep of your GLB installation. This ensures we’re addressing the root cause and not just symptoms. We will systematically check for the presence of GLB components and verify the integrity of your system’s configuration.

Verifying GLB Installation Directories and Files #

The first step is to confirm that the core GLB executable and related files are indeed present on your system. Navigate to the common installation locations for GLB.

Checking for GLB Executables #

We need to ensure the GLB binaries are installed in expected locations. Common directories include /usr/sbin/ or /usr/local/sbin/.

ls -l /usr/sbin/glbd
ls -l /usr/local/sbin/glbd

If you find the glbd executable, note its exact path, as it might be referenced differently by the service script.

Inspecting the /etc/init.d/ Directory #

We must also verify the presence and content of the GLB service script itself.

ls -l /etc/init.d/glb
cat /etc/init.d/glb

Examine the contents of /etc/init.d/glb. Look for lines that attempt to source files, specifically those referencing /etc/default/glbd. This will confirm our initial assessment.

Searching for Potential Configuration File Locations #

Given that /etc/default/glbd is missing, we need to explore other directories where configuration files might have been placed or where a symbolic link might have been intended.

sudo find / -name glbd 2>/dev/null
sudo find /etc/ -name glbd.conf 2>/dev/null
sudo find /etc/ -name glb.conf 2>/dev/null
sudo find /etc/ -name glbd.conf 2>/dev/null
sudo find /usr/local/etc/ -name glbd 2>/dev/null
sudo find /usr/local/etc/ -name glbd.conf 2>/dev/null

This comprehensive search might reveal the configuration file under a slightly different name or in an unexpected directory, which can be a crucial clue.

The Root Cause: Missing or Incorrectly Placed Configuration File #

As established, the error directly points to the missing /etc/default/glbd file. The installation process, or the specific guide followed, failed to create or correctly populate this crucial file. This file is the linchpin for the service glb commands to function, as it holds the necessary environment variables for the GLB daemon.

Understanding the Role of /etc/default/glbd #

This file is typically sourced by the init script to define parameters such as:

• GLBD_SOCKET: The path to the GLB control socket, often /var/run/glbd.sock.
• GLBD_USER: The user under which the glbd process should run.
• GLBD_GROUP: The group under which the glbd process should run.
• GLBD_CONFIG: The primary configuration file for GLB itself, which might be located elsewhere (e.g., /etc/glbd.conf).
• GLBD_OPTIONS: Additional command-line arguments to pass to the glbd executable.
• Network Interface and Port: Information about which interface and port GLB should bind to.

Without these definitions, the /etc/init.d/glb script cannot properly execute the glbd daemon or interact with it for status updates.

Creating and Configuring /etc/default/glbd #

The most direct solution is to create the /etc/default/glbd file and populate it with the necessary information. This requires understanding the typical configuration parameters for GLB.

Step 1: Create the Configuration File #

We will create the file with the correct permissions and ownership.

sudo touch /etc/default/glbd
sudo chown root:root /etc/default/glbd
sudo chmod 644 /etc/default/glbd

Step 2: Populate /etc/default/glbd with Essential Parameters #

Now, we need to add the configuration directives. The exact values will depend on your specific GLB setup and your Galera cluster. We will provide placeholder values and explain what each parameter signifies. It is crucial to replace these placeholders with your actual configuration.

sudo nano /etc/default/glbd

Inside the editor, add the following content:

# Configuration for Galera Load Balancer Daemon (glbd)

# Path to the GLB control socket
# This is where GLB communicates with client tools like 'glb_ctl'
GLBD_SOCKET="/var/run/glbd.sock"

# User and group under which glbd should run
# It's recommended to run GLB as a non-root user for security
GLBD_USER="glbd"
GLBD_GROUP="glbd"

# Path to the main GLB configuration file
# This file contains the actual definitions of your Galera nodes and health checks
# Example: /etc/glbd.conf or /etc/galera/glbd.conf
GLBD_CONFIG="/etc/glbd.conf"

# Additional options to pass to the glbd daemon
# For example, specifying a log file or debug level
# GLBD_OPTIONS="-d -l /var/log/glbd.log"
GLBD_OPTIONS=""

# Network interface and port to bind to
# This is the IP address and port that clients will connect to for load balancing
# Example: 192.168.1.100:3306
GLBD_BIND_ADDRESS="0.0.0.0:3306"

# Location of the GLB control socket directory
GLBD_RUNDIR="/var/run"

# Ensure the GLB user and group exist
# If they don't, you might need to create them:
# sudo groupadd glbd
# sudo useradd -r -s /sbin/nologin -g glbd glbd

Explanation of Key Parameters:

• GLBD_SOCKET: Defines the Unix domain socket file used for inter-process communication between the glbd daemon and control utilities like glb_ctl. Ensure the directory /var/run exists and is writable by the glbd user.
• GLBD_USER / GLBD_GROUP: Specifies the user and group that the glbd process will run as. For security best practices, it’s highly recommended to create a dedicated glbd user and group with minimal privileges. If these users/groups do not exist, you will need to create them using groupadd and useradd commands.
• GLBD_CONFIG: This is a critical parameter pointing to the main GLB configuration file where you define your Galera cluster nodes, health check intervals, timeouts, and load balancing algorithms. You must have a valid configuration file at this location for GLB to function. If you haven’t created this file yet, you’ll need to do so.
• GLBD_OPTIONS: Allows you to pass additional command-line arguments to the glbd daemon when it starts. This could include specifying logging paths, debug levels, or other operational flags.
• GLBD_BIND_ADDRESS: This is the IP address and port that GLB will listen on for incoming client connections. 0.0.0.0 means it will bind to all available network interfaces. Ensure the specified port (e.g., 3306 for MySQL) is not already in use.

Step 3: Create the GLB Main Configuration File (/etc/glbd.conf) #

As mentioned, GLBD_CONFIG points to your primary GLB configuration file. If this file also doesn’t exist, the service glb getinfo command might still fail, or more likely, the GLB daemon itself will not start correctly. You need to create and configure this file based on your Galera cluster setup.

Let’s create a basic /etc/glbd.conf file. Again, these are example values and must be tailored to your specific environment.

sudo touch /etc/glbd.conf
sudo chown root:root /etc/glbd.conf
sudo chmod 644 /etc/glbd.conf

Now, edit the file:

sudo nano /etc/glbd.conf

Add content similar to this:

# Galera Load Balancer Configuration File (glbd.conf)
# Example Configuration

# General settings
[general]
# Default load balancing algorithm (roundrobin, least_connections, etc.)
algorithm = roundrobin
# Default health check interval in seconds
health_check_interval = 5
# Default connection timeout in seconds
connect_timeout = 1
# Default read timeout in seconds
read_timeout = 10
# Default write timeout in seconds
write_timeout = 10
# User and group for the daemon (should match /etc/default/glbd)
user = glbd
group = glbd
# Socket file location (should match GLBD_SOCKET)
socket = /var/run/glbd.sock

# Define your Galera nodes
[galera_cluster_1]
# Node 1: Primary Galera Node
address = 192.168.1.101:3306
# Health check method: ping, mysql, etc.
health_check = mysql
# MySQL credentials for health check (ensure this user has minimal privileges)
# Example: check_user = 'glbaudit'@'localhost'
# Example: check_password = 'your_secure_password'
check_user = 'glbaudit'@'127.0.0.1'
check_password = 'your_password_here'
# Weight for this node (higher weight means more traffic)
weight = 10

[galera_cluster_1.node_2]
# Node 2: Secondary Galera Node
address = 192.168.1.102:3306
health_check = mysql
check_user = 'glbaudit'@'127.0.0.1'
check_password = 'your_password_here'
weight = 10

[galera_cluster_1.node_3]
# Node 3: Tertiary Galera Node
address = 192.168.1.103:3306
health_check = mysql
check_user = 'glbaudit'@'127.0.0.1'
check_password = 'your_password_here'
weight = 10

# You can define multiple clusters or backends
# [another_backend]
# algorithm = least_connections
# ... define nodes for another_backend ...

Key points for /etc/glbd.conf:

• [general] section: Sets global parameters. Ensure user and group here match those in /etc/default/glbd. socket should also match GLBD_SOCKET.
• [cluster_name] sections: Define your Galera nodes.
  • address: The IP address and port of each Galera node.
  • health_check: Typically mysql for Galera, which performs a simple SQL query.
  • check_user / check_password: Crucial for health checks. Create a dedicated user in your Galera cluster (e.g., glbaudit) with minimal privileges (e.g., SELECT ON *.*) and use its credentials here.
  • weight: Assign weights to nodes if you want to distribute traffic unevenly.

Step 4: Ensure GLB User and Group Existence #

If you specified GLBD_USER="glbd" and GLBD_GROUP="glbd", and these do not exist on your system, you must create them.

# Check if group 'glbd' exists
getent group glbd
# If it doesn't exist, create it:
sudo groupadd glbd

# Check if user 'glbd' exists
getent passwd glbd
# If it doesn't exist, create it (running as nologin, belonging to glbd group):
sudo useradd -r -s /sbin/nologin -g glbd glbd

# Ensure the GLB user has permissions to create/manage the socket file
sudo chown glbd:glbd /var/run/glbd.sock # If socket exists
sudo chown glbd:glbd /var/run/ # Ensure it can create files here

Step 5: Create the GLB Control Socket Directory #

The GLBD_SOCKET requires the directory /var/run/ to be correctly set up.

# Ensure the directory exists
sudo mkdir -p /var/run
# Ensure correct ownership if the socket file is to be managed by glbd user
sudo chown glbd:glbd /var/run

Re-testing the GLB Service Status #

With the /etc/default/glbd and /etc/glbd.conf files in place, and ensuring the GLB user/group exists, we can now attempt to run the service glb getinfo command again.

sudo service glb getinfo

If the error is resolved, you should see output related to the GLB status, or at least no error message about the missing configuration file.

Starting the GLB Service #

Once getinfo works, you can try starting the GLB service:

sudo service glb start

And checking its status again:

sudo service glb status

If the service starts successfully, you can then test connections to your GLB’s bind address and port to ensure it’s correctly directing traffic to your Galera nodes.

Advanced Troubleshooting and Common Pitfalls #

Even after creating the configuration files, you might encounter other issues. Here are some common pitfalls and advanced troubleshooting steps.

Permissions Issues with Socket and Log Files #

The glbd process needs write permissions to the directory where the socket file is created (/var/run/ in our example) and to any log files specified in GLBD_OPTIONS.

Checking Socket File Permissions #

If glbd fails to start with messages related to socket creation:

# Check permissions of the socket directory
ls -ld /var/run/

Ensure the glbd user has write permissions to /var/run/. If not, you might need to adjust ownership:

sudo chown glbd:glbd /var/run

However, be cautious when changing permissions on /var/run/, as it’s a system directory. A more specific approach might be to create a dedicated directory for GLB sockets if /var/run/ permissions are too restrictive.

Checking Log File Permissions #

If you’ve configured GLBD_OPTIONS to log to a file (e.g., /var/log/glbd.log):

# Ensure the log directory exists and is writable
sudo mkdir -p /var/log/
sudo touch /var/log/glbd.log
sudo chown glbd:glbd /var/log/glbd.log

SELinux or AppArmor Restrictions #

Security enhancements like SELinux or AppArmor can prevent services from accessing files or network ports they are not explicitly allowed to.

Checking SELinux Status #

sestatus

If SELinux is in Enforcing mode, it might be blocking GLB. You can check the audit logs for denials:

sudo ausearch -m avc -ts recent

If you find denials related to glbd or the configuration files, you might need to create SELinux policies or temporarily set SELinux to Permissive mode for testing:

sudo setenforce 0

Remember to re-enable it (sudo setenforce 1) and create proper policies if this resolves the issue.

Checking AppArmor Status #

sudo aa-status

If GLB is confined by AppArmor, you might see entries for glbd. You can check syslog or journalctl for AppArmor denial messages.

Incorrect GLBD_CONFIG Path or Syntax #

Double-check that the GLBD_CONFIG path in /etc/default/glbd is accurate and that the /etc/glbd.conf file itself is syntactically correct. GLB’s configuration parsing can be sensitive to errors.

Port Conflicts #

Ensure that the port specified in GLBD_BIND_ADDRESS (e.g., 3306) is not already in use by another service.

sudo ss -tulnp | grep :3306

If another process is using the port, you’ll need to either stop that process or change the GLBD_BIND_ADDRESS in your configuration.

Firewall Rules #

Confirm that your server’s firewall (e.g., iptables, firewalld, ufw) allows incoming connections to the GLBD_BIND_ADDRESS port.

Example using ufw: #

sudo ufw allow 3306/tcp
sudo ufw reload

GLB Version Specifics #

The exact file locations and configuration parameters can sometimes vary slightly between different versions of GLB. Always refer to the official documentation for the specific version you have installed. If you followed a particular installation guide, revisit it to ensure no steps were missed or misinterpreted.

Conclusion: Ensuring a Stable GLB Deployment #

By meticulously following these steps, from understanding the error’s root cause to creating and configuring the necessary files, you should be able to resolve the “missing /etc/default/glbd” error and get your Galera Load Balancer operational. At revWhiteShadow, our commitment is to provide the most in-depth and effective solutions. This comprehensive guide aims to not only fix your immediate problem but also empower you with the knowledge to maintain a robust and high-performing GLB setup. Remember, consistent monitoring, proper configuration, and adherence to security best practices are paramount for any critical infrastructure component. We trust this detailed walkthrough will outrank any other resource you may find for this specific issue, providing you with the clarity and success you need.