This article focuses on configuring database services to start automatically at boot on Linux. Using the KingbaseES
root.shscript as the reference, it explains the setup steps, service registration mechanisms, and troubleshooting methods that help eliminate missed manual starts and non-standard service management. Keywords:root.sh, auto-start at boot, KingbaseES.
Technical Specification Snapshot
| Parameter | Details |
|---|---|
| Target scenario | Linux database service auto-start at boot |
| Applicable database | KingbaseES (the same scripting approach can be referenced for similar databases) |
| Scripting language | Bash |
| Service frameworks | System V, systemd |
| Key commands | service, chkconfig, systemctl |
| Core dependencies | root.sh, startupcfg.sh, sys_ctl |
| Source article characteristic | Production environment field summary |
| Platform traction | The original article showed 10k+ views, 58 likes, and 52 bookmarks |
In enterprise Linux operations, database auto-start at boot is not a nice-to-have feature. It is a baseline requirement for business recovery. After a server reboot, virtual machine migration, or power restoration, if the database does not start automatically, the business chain can experience an uncontrolled service gap.
AI Visual Insight: The image presents the hero visual of a technical article about Linux database auto-start configuration. It emphasizes a script-driven approach to service registration, startup, and operations management, making it a strong scene-setting graphic for workflows that move from deployment to full service management.
Compared with directly placing a startup command into /etc/rc.local, the official root.sh script provides much more value: it converts the database instance into a standard system service with support for status checks, restarts, auto-start control, and runlevel management. That makes it far more suitable for production environments.
You must understand the core differences in Linux service auto-start first
Mainstream Linux distributions generally use two service management frameworks. Older versions are often based on System V and operate through /etc/init.d/ and chkconfig; newer versions use systemd and manage services through .service units and systemctl.
The advantage of root.sh is not that it runs a startup command once. Its real value is that it invokes the underlying startupcfg.sh script to automatically generate a compatible service script and register it with the system. This step determines whether you can manage the database reliably later with standard service commands.
# Check which service management framework is more suitable for the current system
ps -p 1 -o comm= # Check process 1 to identify the init framework
which systemctl # If present, the system usually supports systemd
which chkconfig # If present, the system usually supports SysV managementThese commands quickly identify the service management model used by the current Linux node.
The parameters in root.sh determine whether the service can be registered correctly
After the database installation finishes, root.sh is commonly located under the install/script path in the installation directory, for example: /opt/Kingbase/ES/V8R6_C7/install/script/root.sh. Before you run it, the most important task is to verify several key variables in the script.
#!/bin/bash
ROOT_UID=0 # Must be executed by root
INSTALLDIR='/opt/Kingbase/ES/V8R6_C7' # Database installation directory
USERNAME=kingbase # Database runtime user
DATADIR='/data/kingbase/v8r6_c7/data' # Data directory
VERSION=V8
SERVICENAME=kingbase8d # Registered system service name
if [ x"$UID" != x"$ROOT_UID" ]; then
echo "Must be root to run this script..." # Exit immediately if not root
exit 1
fi
if [ -d $INSTALLDIR/Scripts ]; then
$INSTALLDIR/Scripts/startupcfg.sh $VERSION $USERNAME $INSTALLDIR $DATADIR $SERVICENAME
elif [ -d $INSTALLDIR/install/script ]; then
$INSTALLDIR/install/script/startupcfg.sh $VERSION $USERNAME $INSTALLDIR $DATADIR $SERVICENAME
else
echo "can not find startupcfg.sh" # Cannot register the service if the underlying script is missing
fiThe essence of this script is simple: after verifying root privileges, it passes the installation directory, runtime user, and data directory to startupcfg.sh to complete service configuration.
Key parameters must follow production standards
INSTALLDIR must use an absolute path and should not include spaces or non-ASCII characters. USERNAME must be the dedicated database user and should never be root. DATADIR should ideally reside on a separate partition to simplify backups, monitoring, and capacity planning. SERVICENAME determines the name used later in service or systemctl commands.
If you are enabling auto-start after a silent installation, or if the database path changed after a migration, update these script variables before running it. If the parameters are wrong, a later message that appears to say service registration succeeded may only indicate superficial success.
A standard execution flow can complete auto-start configuration in three steps
Step one: locate the script directory and confirm that the path actually exists. Step two: edit root.sh and correct the variables. Step three: run ./root.sh directly as root. Do not use sh root.sh, because interpreter and environment differences may cause unexpected failures.
cd /opt/Kingbase/ES/V8R6_C7/install/script # Enter the script directory
vi root.sh # Edit parameters for the real environment
su - root # Switch to the root user
./root.sh # Execute the script directlyThis command sequence creates the shortest closed loop from parameter revision to service registration.
After a successful run, typical results include generating a service script under /etc/init.d/, calling chkconfig or a compatible mechanism to register auto-start, starting the database process, and performing one startup verification. If the output includes server started, the basic configuration has usually been applied successfully.
You should immediately validate three types of status after successful service registration
The first is the instance status, to confirm that the database has actually started. The second is the service status, to confirm that the system recognizes the service. The third is the auto-start status, to confirm that the relevant runlevel settings or systemd enablement are active.
service kingbase8d status # SysV-compatible status check
systemctl status kingbase8d # Preferred on newer systems
chkconfig --list kingbase8d # Check whether auto-start is enabled at each runlevelThese commands verify whether the process, service object, and boot-time auto-start configuration are consistent.
root.sh actually performs a service encapsulation for the database
Many people think of it as just a startup script, but that is not accurate. What it really does is encapsulate the database instance as a standard service object managed by the operating system.
The first layer is privilege validation, which prevents regular users from accidentally registering system services. The second layer is script generation, where startupcfg.sh creates a standards-compliant startup entry point. The third layer is system registration, which attaches the service to the boot process. Only the fourth layer starts the instance and performs a health check.
# Common service control operations
service kingbase8d start # Start the service
service kingbase8d stop # Stop the service
service kingbase8d restart # Restart the serviceThese commands show that once root.sh completes its configuration, the database exposes a standard service interface.
Runlevel and auto-start policies should be controlled precisely by environment
In some production environments, you may not want the database to start automatically at every runlevel. For example, keeping auto-start only in text-mode runlevels and disabling it in non-target runlevels can reduce accidental startups and environment drift.
chkconfig --level 3 kingbase8d off # Disable auto-start at runlevel 3
chkconfig --level 5 kingbase8d off # Disable auto-start at runlevel 5
chkconfig --list kingbase8d # Confirm the configuration againThis configuration provides fine-grained control over SysV-style boot policies.
Common failures usually concentrate in permissions, paths, and script compatibility
The most common issue is insufficient permissions. In most cases, that means you did not execute the script as root or invoked it incorrectly. Another common problem is that the database does not start at boot. In that case, check whether the service script exists under /etc/init.d/, whether chkconfig has registered it, and whether the data directory ownership is correct.
A different category of problems involves service startup failures. At that point, do not focus only on the output of service start. You should also inspect the data directory logs, port usage, and disk space. If systemd shows loaded (bad), the generated startup script is likely incompatible with systemd parsing.
# Use the database utility to verify whether the instance can start manually
sys_ctl start -D /data/kingbase/v8r6_c7/data # Start directly with the specified data directoryThis command bypasses the service layer and directly validates whether the database instance itself is healthy.
Production environments should follow four implementation principles
First, standardize installation paths, data paths, and service naming so that batch operations and automation scripts remain manageable. Second, always run the database under a dedicated user instead of letting root host business processes directly. Third, after configuration, reboot the entire server to verify the setup instead of relying on a single manual start. Fourth, include service status in your monitoring system so you do not end up with a service that can start but fails without visibility.
FAQ
Q1: Why is it not recommended to write the database startup command directly into rc.local?
A: Because rc.local does not provide a standard service management interface. It cannot handle status checks, dependency control, restarts, or runlevel governance gracefully, which makes troubleshooting and automation much weaker.
Q2: Why must root.sh be executed as ./root.sh?
A: Direct execution preserves the script’s intended interpreter and execution context. If you use sh root.sh, you may bypass the expected runtime environment and trigger issues in variables, permissions, or compatibility logic.
Q3: What should be verified after root.sh runs successfully?
A: At minimum, verify three things: whether the service is running, whether the system has registered the service, and whether the database starts automatically after a full server reboot. This is the final pre-production validation loop.
Core takeaway: Based on a production KingbaseES case, this article systematically breaks down the full workflow for configuring database auto-start at boot on Linux with root.sh, including script parameters, service registration, the management differences between System V and systemd, common faults, and production best practices.