glbd: No such file” Error in GLB Installation

Experiencing the error message /etc/init.d/glb: .: cannot open /etc/default/glbd: No such file during the setup of the Galera Load Balancer (GLB) can be a frustrating roadblock. This particular message indicates a critical issue with the configuration file that the GLB initialization script relies upon. At revWhiteShadow, we understand the importance of a smooth and successful Galera Cluster setup, and we’ve meticulously researched and tested solutions to help you overcome this common hurdle. Our goal is to provide you with the comprehensive guidance necessary to get your GLB operational, ensuring high availability and optimal performance for your database cluster.

This article delves deep into the root causes of this error and presents a robust, step-by-step methodology to rectify it. We will guide you through verifying your installation, identifying missing components, and implementing the correct configuration to resolve the /etc/init.d/glb: .: cannot open /etc/default/glbd: No such file error, enabling you to proceed with confidence in your Galera Load Balancer deployment.

Understanding the `/etc/init.d/glb: .: cannot open /etc/default/glbd: No such file` Error

The error message itself is quite descriptive. It tells us that the script located at /etc/init.d/glb is attempting to execute a command (.) which is likely sourcing another file. The specific file it’s trying to open is /etc/default/glbd, and the error “No such file” clearly states that this file does not exist in the expected location.

In the context of Linux system administration and service management, files within the /etc/init.d/ directory are typically shell scripts responsible for starting, stopping, and managing system services. These scripts often rely on configuration files to define parameters, variables, and settings specific to the service they manage. The /etc/default/ directory is a standard location for system-wide default configurations for various services.

Therefore, when the service glb getinfo command is executed, the /etc/init.d/glb script is invoked. This script, in turn, attempts to read settings from /etc/default/glbd. If /etc/default/glbd is missing, the script cannot proceed, leading to the observed error.

This usually signifies one of two primary issues:

Incomplete Installation: The GLB installation process might not have completed successfully, failing to create the necessary configuration file.
Incorrect File Path or Naming: There might be a discrepancy in the expected file path or the filename itself, either due to manual errors or variations in installation methods.

Our approach at revWhiteShadow is to systematically address these potential causes to ensure a definitive resolution.

Verifying Your GLB Installation and Prerequisites

Before diving into creating the missing file, it’s paramount to ensure that the core GLB installation itself is sound. A flawed installation can lead to a cascade of subsequent errors. The official Galera Cluster documentation you referenced is an excellent starting point, and we will reiterate key verification steps.

#### Confirming GLB Binaries Presence

The Galera Load Balancer binaries are typically part of the Galera Cluster Enterprise Edition. Ensure that you have indeed downloaded and installed the correct package that includes GLB.

Check Binary Locations: Navigate to common installation directories where binaries are typically placed. This often includes /usr/local/sbin/ or /usr/sbin/. You should find an executable file named glb.
```
ls -l /usr/local/sbin/glb
ls -l /usr/sbin/glb
```
If you cannot locate the glb executable, you may need to revisit the installation steps for the Galera Cluster Enterprise Edition and ensure that GLB was included and successfully compiled/installed.

#### Checking GLB Configuration Directory

While the error points to /etc/default/glbd, it’s worth confirming the presence of any GLB-related configuration files or directories.

Examine /etc/ for GLB-related files:
```
ls -l /etc/glb/
ls -l /etc/galera/
```
While /etc/default/glbd is specifically required by the init script, other configuration files or directories might provide clues about your installation’s structure.

#### Understanding the `service glb getinfo` Command

The service command is a standard interface for managing system services on many Linux distributions. The glb getinfo command is a custom action defined within the /etc/init.d/glb script. This command is designed to query the status or retrieve information about the GLB service. The fact that this specific command fails suggests that the init script itself is present but unable to execute its internal logic due to missing dependencies, such as configuration files.

Addressing the Missing `/etc/default/glbd` File

The most direct solution to the No such file error is to create the missing file. However, simply creating an empty file might not be sufficient. The init script expects specific variables to be defined within this file. Based on common practices and the structure of such init scripts, we can infer the likely content required.

#### Creating the `/etc/default/glbd` File

We will create this file with appropriate content. The most common and recommended approach is to place it in the /etc/default/ directory.

Create the directory if it doesn’t exist:
```
sudo mkdir -p /etc/default/
```
Create the glbd file:
```
sudo nano /etc/default/glbd
```
(You can use vi, vim, or any other preferred text editor.)

#### Essential Configuration Variables for `/etc/default/glbd`

The /etc/init.d/glb script likely expects certain environment variables to be set in /etc/default/glbd to correctly manage the GLB service. While the exact variables can vary slightly based on the specific version and distribution, common ones include:

GLB_CONFIG: This variable typically points to the main GLB configuration file, often named glbd.cnf or similar.
GLB_USER: The user under which the GLB process should run.
GLB_GROUP: The group under which the GLB process should run.
GLB_LOGFILE: The path to the GLB log file.
GLB_PIDFILE: The path to the GLB process ID (PID) file.

Let’s populate /etc/default/glbd with sensible defaults. You will need to adjust these paths and values based on your specific GLB installation and system configuration.

# /etc/default/glbd

# Path to the GLB configuration file.
# This is the main configuration file for the Galera Load Balancer itself.
# A common location is /etc/galera/glbd.cnf or /etc/glbd.cnf.
# Ensure this file actually exists and is correctly configured.
GLB_CONFIG="/etc/galera/glbd.cnf"

# User and group under which the GLB daemon should run.
# It's recommended to run services with a dedicated, non-privileged user.
GLB_USER="gluser" # Replace with your actual GLB user if different
GLB_GROUP="glgroup" # Replace with your actual GLB group if different

# Path for the GLB daemon's log file.
# Ensure the directory exists and the user specified above has write permissions.
GLB_LOGFILE="/var/log/glbd.log"

# Path for the GLB daemon's process ID (PID) file.
# This is used by the init script to track the running process.
GLB_PIDFILE="/var/run/glbd.pid"

# Additional options that can be passed to the glbd command.
# For example, you might specify a particular interface or port.
# GLB_OPTS="-i eth0 -p 3306"
# GLB_OPTS=""

Important Considerations for the Variables:

GLB_CONFIG: This is arguably the most critical variable. You must ensure that the file path specified here (/etc/galera/glbd.cnf in our example) actually exists and contains a valid GLB configuration. If you haven’t created this file yet, you will need to do so separately. We will cover its creation in a subsequent section.
GLB_USER and GLB_GROUP: You should create a dedicated user and group for the GLB service if you haven’t already. This enhances security by isolating the GLB process.
```
sudo groupadd glgroup
sudo useradd -r -g glgroup -s /sbin/nologin gluser
```
Then, ensure the directories for log files and PID files are owned by this user and group.
GLB_LOGFILE and GLB_PIDFILE: The directories for these files (/var/log/ and /var/run/) usually exist. However, you need to ensure the GLB_USER has write permissions to them.
```
sudo touch /var/log/glbd.log
sudo chown gluser:glgroup /var/log/glbd.log
sudo touch /var/run/glbd.pid
sudo chown gluser:glgroup /var/run/glbd.pid
```
Note: /var/run/ is often a temporary filesystem (tmpfs). PID files might be recreated on reboot. Some systems might prefer /var/run/glbd/ as a directory for the PID file, and the init script should be capable of creating it if needed.

#### Creating the GLB Configuration File (`glbd.cnf`)

As mentioned, GLB_CONFIG points to the GLB configuration file. The error you encountered might be compounded by the absence of this file as well. The Galera documentation provides a sample configuration.

Create the configuration directory if necessary:
```
sudo mkdir -p /etc/galera/
```
Create the glbd.cnf file:
```
sudo nano /etc/galera/glbd.cnf
```

Here’s a sample glbd.cnf that you can adapt. You will need to tailor the wsrep_cluster_address to match your Galera Cluster’s node addresses and ports.

# /etc/galera/glbd.cnf
# Galera Load Balancer Configuration

[mysqld]
# Socket path used by the Galera Load Balancer to communicate with clients.
# Ensure this path matches the socket your MySQL clients are configured to use
# or the path you intend for GLB to listen on if not using TCP.
# For TCP, this section is less relevant unless you want GLB to bind to a local socket.
# socket = /var/run/mysqld/mysqld.sock

[glbd]
# The Galera Load Balancer specific configuration.

# This is the address and port GLB will bind to and listen for client connections.
# Use 0.0.0.0 to listen on all available network interfaces.
bindaddr = 0.0.0.0
port = 3306 # The default MySQL port, or choose another if needed

# This is the address and port of the Galera cluster nodes.
# GLB uses this to connect to the Galera cluster and monitor their health.
# The format is 'mysql://user:password@host:port'.
# Ensure the user has sufficient privileges (e.g., PROCESS, REPLICATION CLIENT).
# If you have multiple nodes, list them separated by commas.
# Example: wsrep_cluster_address = "mysql://glbuser:password@192.168.1.10:3306,mysql://glbuser:password@192.168.1.11:3306"
# Replace with your actual cluster node IPs and the user/password you've set up for GLB access.
wsrep_cluster_address = "mysql://glbuser:password@192.168.1.100:3306,mysql://glbuser:password@192.168.1.101:3306"

# The user and password GLB will use to connect to the Galera nodes.
# It's highly recommended to create a dedicated user for GLB with minimal privileges.
# Example:
# wsrep_cluster_user = glbuser
# wsrep_cluster_password = password

# The name of the GLB daemon. This is typically 'glbd'.
daemon_name = glbd

# Log file for GLB. This can also be managed by GLB_LOGFILE in /etc/default/glbd,
# but specifying it here can override or supplement.
# log_file = /var/log/glbd.log

# PID file for GLB. Similar to log_file, can be managed by GLB_PIDFILE.
# pid_file = /var/run/glbd.pid

# Timeout for connecting to Galera nodes (in seconds).
connect_timeout = 10

# Timeout for waiting for a response from Galera nodes (in seconds).
read_timeout = 10

# Number of retries when connecting to a Galera node.
retry_count = 5

# Interval between health checks of Galera nodes (in seconds).
# This determines how often GLB checks if a node is still healthy.
health_check_interval = 5

# Load balancing algorithm. Common options are 'roundrobin' or 'leastconnected'.
# 'roundrobin' distributes requests sequentially.
# 'leastconnected' sends requests to the node with the fewest active connections.
load_balance_algorithm = roundrobin

# Specifies how GLB handles node failures.
# 'failover' means GLB will stop sending traffic to a failed node.
# 'failback' means GLB will attempt to send traffic back to a node once it recovers.
# failover = failover
# failback = failback

# If using 'failover' and 'failback', you might want to configure a grace period
# before a recovered node starts receiving traffic again.
# failback_grace_period = 30 # seconds

# Enable or disable debugging messages. Set to 1 for debugging.
# debug = 0

# For TCP/IP connections, specify the bind address and port if not done above.
# bindaddr = 0.0.0.0
# port = 3306

# Optional: If you want GLB to listen on a specific network interface.
# interface = eth0

# Optional: If you want GLB to enforce specific SQL modes on clients.
# sql_mode = STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION

# Optional: If you want GLB to automatically start on boot.
# This is usually handled by the init script itself, but can sometimes be configured here.
# autostart = true

# Optional: If you want to restrict access to GLB based on source IP addresses.
# Use a comma-separated list of allowed IP addresses or subnets.
# allow_from = 192.168.1.0/24, 10.0.0.5

# Optional: Specify the maximum number of concurrent connections GLB will handle.
# max_connections = 1000

Crucial Steps for glbd.cnf:

wsrep_cluster_address: This is vital. You need to list the IPs and ports of your Galera Cluster nodes. If you have multiple nodes, separate them with commas. Ensure the glbuser and password are correct and that this user has the necessary permissions on your Galera nodes.
User Permissions: The user specified in wsrep_cluster_address (e.g., glbuser) must exist on all your Galera nodes and have privileges like PROCESS and REPLICATION CLIENT.
```
-- On each Galera node:
CREATE USER 'glbuser'@'%' IDENTIFIED BY 'password';
GRANT PROCESS, REPLICATION CLIENT ON *.* TO 'glbuser'@'%';
FLUSH PRIVILEGES;
```
Replace '%' with the specific IP address of the GLB server if you want to restrict access.
bindaddr and port: Ensure these are set correctly for how you want GLB to be accessible.

Revisiting the Init Script and Service Command

With the necessary configuration files in place, we can now attempt to use the service command again.

#### Making the Init Script Executable

Ensure the /etc/init.d/glb script itself has execute permissions.

sudo chmod +x /etc/init.d/glb

#### Testing the `service glb getinfo` Command

Now, try the command again:

sudo service glb getinfo

If the /etc/default/glbd file is correctly populated and glbd.cnf is valid, this command should now provide information about the GLB service (e.g., “glb is not running” or status details if it were running).

#### Starting the GLB Service

Once getinfo works, you can attempt to start the service:

sudo service glb start

#### Checking GLB Status

After starting, check its status:

sudo service glb status

You can also use ps aux | grep glbd to see if the glbd process is running.

#### Stopping the GLB Service

To stop the service:

sudo service glb stop

#### Restarting the GLB Service

To restart the service:

sudo service glb restart

Troubleshooting Common Post-Creation Issues

Even after creating the files, you might encounter further issues. Here are some common ones and their resolutions.

#### “Permission denied” Errors

If you see “Permission denied” when trying to start GLB, it often relates to file permissions for log files, PID files, or the configuration file itself.

Check ownership and permissions:
```
ls -l /var/log/glbd.log
ls -l /var/run/glbd.pid
ls -l /etc/galera/glbd.cnf
ls -l /etc/init.d/glb
```
Ensure that the user defined in GLB_USER (e.g., gluser) has read access to the configuration file and write access to the log and PID file locations.

#### GLB Fails to Start After `service glb start`

If service glb start doesn’t produce an error but GLB doesn’t appear to be running (ps aux | grep glbd shows nothing), check the GLB log file (/var/log/glbd.log in our example).

Examine /var/log/glbd.log:
```
sudo tail /var/log/glbd.log
```
This log file will likely contain more specific error messages from the glbd process itself, such as issues connecting to the Galera nodes, invalid configuration parameters, or port conflicts.

#### Network or Port Conflicts

If GLB fails to bind to the specified port (e.g., 3306), it usually means another service is already using that port.

Check port usage:
```
sudo ss -tulnp | grep 3306
```
If another process is listening on port 3306, you’ll need to either reconfigure GLB to use a different port or reconfigure the other service.

#### Incorrect `wsrep_cluster_address`

Errors related to connecting to Galera nodes almost always stem from an incorrect wsrep_cluster_address in glbd.cnf.

Verify node reachability: Ensure you can ping the Galera node IPs from the server where GLB is installed.
Verify connectivity: Use telnet or nc to test if you can connect to the MySQL port on each Galera node from the GLB server.
```
telnet 192.168.1.100 3306
```
(Press Ctrl+] then type quit to exit telnet if it connects.)
Double-check credentials: Ensure the username and password in wsrep_cluster_address are correct and the user has the necessary privileges on all Galera nodes.

Ensuring High Availability with GLB

A correctly functioning Galera Load Balancer is crucial for maintaining the high availability of your database cluster. By ensuring GLB starts and runs reliably, you create a single, stable entry point for your applications to connect to your Galera Cluster, abstracting away the individual node IPs and health status.

#### Automatic Startup on Boot

To ensure GLB automatically starts whenever the server reboots, you need to enable the service using your system’s service management tools.

For Systemd-based systems (most modern Linux distributions like Ubuntu 15.04+, Debian 8+, CentOS 7+, Fedora 15+):
```
sudo systemctl enable glb.service
```
If your init script is named glb, it might be automatically recognized as glb.service. If not, you may need to create a glb.service unit file in /etc/systemd/system/.
For SysVinit-based systems (older distributions or specific configurations): The service glb enable command might exist, or you might need to use chkconfig or update-rc.d.
```
# For Red Hat based systems (RHEL, CentOS 6 and older)
sudo chkconfig glb on

# For Debian based systems (Debian 7 and older, Ubuntu 14.04 and older)
sudo update-rc.d glb defaults
```
These commands create symbolic links in the appropriate runlevel directories to ensure the script is executed on boot.

#### Monitoring GLB Health

Beyond just starting, continuous monitoring of GLB is important.

Regularly check GLB logs: Keep an eye on /var/log/glbd.log for any recurring errors or warnings.
Monitor process status: Use sudo service glb status or ps aux | grep glb periodically.
Application-level monitoring: Ensure your applications can connect and perform operations through GLB. If applications start failing, GLB might be the bottleneck or a point of failure.

Conclusion

Resolving the /etc/init.d/glb: .: cannot open /etc/default/glbd: No such file error requires a systematic approach, starting with understanding the error’s context and then meticulously creating and configuring the missing files. By following the detailed steps provided by revWhiteShadow, including creating /etc/default/glbd with appropriate variables and ensuring your glbd.cnf is correctly populated and points to your Galera Cluster nodes, you can overcome this common installation hurdle.

Remember to verify user permissions, log file locations, and network accessibility for the Galera nodes. A correctly configured Galera Load Balancer is a cornerstone of a robust and highly available database architecture. If you encounter persistent issues, always refer back to the GLB configuration file and the GLB daemon’s logs for more specific diagnostic information. With this comprehensive guide, you are well-equipped to get your Galera Load Balancer operational and safeguard your database cluster’s availability.

/etc/init.d/glb . cannot open /etc/default/glbd Nosuch file

Resolving the “/etc/init.d/glb: .: cannot open /etc/default/glbd: No such file” Error in GLB Installation #

Understanding the /etc/init.d/glb: .: cannot open /etc/default/glbd: No such file Error #

Verifying Your GLB Installation and Prerequisites #

#### Confirming GLB Binaries Presence #

#### Checking GLB Configuration Directory #

#### Understanding the service glb getinfo Command #

Addressing the Missing /etc/default/glbd File #

#### Creating the /etc/default/glbd File #

#### Essential Configuration Variables for /etc/default/glbd #

#### Creating the GLB Configuration File (glbd.cnf) #

Revisiting the Init Script and Service Command #

#### Making the Init Script Executable #

#### Testing the service glb getinfo Command #

#### Starting the GLB Service #

#### Checking GLB Status #

#### Stopping the GLB Service #

#### Restarting the GLB Service #

Troubleshooting Common Post-Creation Issues #

#### “Permission denied” Errors #

#### GLB Fails to Start After service glb start #

#### Network or Port Conflicts #

#### Incorrect wsrep_cluster_address #

Ensuring High Availability with GLB #

#### Automatic Startup on Boot #

#### Monitoring GLB Health #

Conclusion #