如何在Puppet中为RedHat 7.2创建系统服务

Got it, let's tackle this—since you're on RHEL 7.2 (which uses systemd instead of the old chkconfig/SysV init), here are two solid approaches to manage your custom service with Puppet, depending on whether you want to reuse your existing init script or switch to native systemd configs.

方案1：复用现有init.d脚本（兼容systemd） #

Systemd still supports traditional SysV init scripts, so you don't have to rewrite everything right away. First, make sure your existing init script includes the LSB header (systemd uses this to parse metadata like dependencies). A basic LSB header looks like this at the top of your script:

### BEGIN INIT INFO
# Provides:          my-custom-service
# Required-Start:    $local_fs $network
# Required-Stop:     $local_fs
# Default-Start:     3 4 5
# Default-Stop:      0 1 2 6
# Short-Description: My custom application service
# Description:       Starts and stops the custom application daemon
### END INIT INFO

Once your script is ready, use Puppet to deploy it and manage the service:

# Copy your custom init script to the standard location
file { '/etc/init.d/my-custom-service':
  source => 'puppet:///modules/your-module-name/my-custom-service',
  mode   => '0755',
  owner  => 'root',
  group  => 'root',
}

# Manage the service: enable on boot and ensure it's running
service { 'my-custom-service':
  ensure     => running,
  enable     => true,
  hasstatus  => true,  # Set to false if your script doesn't support `status` command
  hasrestart => true,  # Set to false if your script doesn't support `restart`
  require    => File['/etc/init.d/my-custom-service'],
}

Puppet automatically detects that RHEL 7 uses systemd, so it will use systemctl enable and systemctl start under the hood—no need to call chkconfig manually anymore.

方案2：使用原生systemd服务文件（推荐） #

For long-term maintainability, native systemd service files are better—they're more flexible, support more features (like automatic restarts, dependency management, and logging integration), and are the standard on modern RHEL systems.

Step 1: Create a systemd service file #

First, write a .service file (e.g., my-custom-service.service) with content like this:

[Unit]
Description=My Custom Application Service
After=network.target  # Start only after the network is up

[Service]
Type=forking  # Use this if your start script forks to the background; use `simple` for foreground apps
ExecStart=/path/to/your/custom-start-script.sh
ExecStop=/path/to/your/custom-stop-script.sh
Restart=on-failure  # Optional: Auto-restart if the service crashes
User=root  # Optional: Run the service as a non-root user if possible

[Install]
WantedBy=multi-user.target  # Enable when the system reaches multi-user mode

Step 2: Deploy and manage with Puppet #

Use Puppet to push the service file, reload systemd, and manage the service state:

# Deploy the systemd service file
file { '/etc/systemd/system/my-custom-service.service':
  source => 'puppet:///modules/your-module-name/my-custom-service.service',
  mode   => '0644',
  owner  => 'root',
  group  => 'root',
  notify => Exec['systemctl-daemon-reload'],  # Trigger a reload if the file changes
}

# Reload systemd to pick up new/updated service files
exec { 'systemctl-daemon-reload':
  command     => 'systemctl daemon-reload',
  path        => '/usr/bin:/usr/sbin',
  refreshonly => true,  # Only run when the service file is updated
}

# Enable and start the service
service { 'my-custom-service':
  ensure    => running,
  enable    => true,
  require   => [File['/etc/systemd/system/my-custom-service.service'], Exec['systemctl-daemon-reload']],
}

Key Notes #

• For the Type parameter in the systemd service file:
  • simple: Use if your service runs in the foreground (doesn't fork)
  • forking: Use if your start script creates a background daemon
  • oneshot: Use for one-time tasks (like initialization scripts)
• Always test your service manually first with systemctl start my-custom-service and systemctl enable my-custom-service before deploying via Puppet—this helps catch issues early.
• If you go with the init.d approach and your script doesn't support status, Puppet will fall back to checking if the process is running via its PID.

内容的提问来源于stack exchange，提问作者user1074593