Configuring Multiple Process Startup in Systemd Services: Methods and Best Practices

Overview of Systemd Multi-Process Startup Mechanisms

In Linux system service management, Systemd as a modern init system provides flexible service configuration capabilities. When needing to start multiple instances of the same script with different parameters, developers often face challenges in efficient configuration.

Limitations of Single Service Units

In Systemd service configuration, Type=simple service units support only a single ExecStart directive. Attempting to configure multiple ExecStart entries will prevent Systemd from starting the service correctly. This design stems from the nature of simple type services—they expect the service process to run continuously as the main process.

While ExecStartPre and ExecStartPost can be used to execute additional commands, these directives are not suitable for long-running processes. They execute serially before and after the main service starts, and each command must complete before the next begins, making them inappropriate for scenarios requiring parallel execution of multiple independent processes.

Serial Execution with oneshot Type

When a service is configured as Type=oneshot, multiple ExecStart directives can indeed be specified. However, these commands execute sequentially rather than in parallel. Each ExecStart must complete fully before the next begins, limiting applicability in scenarios requiring concurrent processing.

The serial execution characteristic makes oneshot type more suitable for initialization scripts or tasks requiring strict sequential execution, but not for multiple independent service processes that need to run simultaneously.

Template Units: Parameterized Service Configuration

For scenarios requiring multiple instances of the same service with different parameters, Systemd's template units provide an elegant solution. By creating template service files, parameterized service configuration can be achieved.

Create a template unit file /etc/systemd/system/foo@.service:

[Unit]
Description=Script description %I

[Service]
Type=simple
ExecStart=/script.py %i
Restart=on-failure

[Install]
WantedBy=multi-user.target

In this configuration, %i serves as an instance parameter placeholder, which Systemd replaces with actual parameter values during service startup. This approach enables launching multiple service instances with different parameters from the same template.

The command to start multiple service instances is:

systemctl start foo@parameter1.service foo@parameter2.service

Each service instance runs as an independent process, achieving true parallel execution. This method is particularly suitable for scenarios requiring dynamic creation of service instances based on configuration parameters.

Parallel Management Through Target Dependencies

Another approach to achieve parallel startup of multiple services is using target dependencies. By creating custom targets, multiple related services can be organized together for unified startup management.

First, create the target unit file /etc/systemd/system/bar.target:

[Unit]
Description=Bar target
Requires=multi-user.target
After=multi-user.target
AllowIsolate=yes

Then modify the service unit files to point their dependencies to the custom target:

[Unit]
Description=Script description %I

[Service]
Type=simple
ExecStart=/script.py %i
Restart=on-failure

[Install]
WantedBy=bar.target

After configuration, enable and start the services using:

systemctl daemon-reload
systemctl enable foo@param1.service
systemctl enable foo@param2.service
systemctl start bar.target

This method is not limited to template units and can be applied to any type of service unit, providing greater flexibility.

Analysis of Practical Application Scenarios

The SSH tunnel maintenance scenario mentioned in the reference article effectively demonstrates practical needs for multi-service configuration. When maintaining multiple SSH tunnels, using template units avoids creating numerous duplicate service files.

However, with the growing adoption of infrastructure-as-code principles, many developers are turning to configuration management tools like Ansible and TerraForm to handle such requirements. These tools offer more powerful templating and looping configuration capabilities, enabling service configuration management at a higher level.

Configuration Selection Strategy

When choosing a multi-service configuration approach, consider the following factors:

Template Unit Approach is suitable for scenarios with relatively fixed parameter variations and predictable numbers of service instances. Its advantages include concise configuration, native Systemd support, and convenient management.

Target Dependency Approach is better suited for complex scenarios requiring organization of multiple different types of services together. It provides additional capabilities for service grouping and dependency management.

Configuration Management Tools may be the better choice when service configurations need dynamic generation, parameter combinations are complex, or unified management across multiple systems is required.

Best Practice Recommendations

Based on the analysis of Systemd multi-process startup mechanisms, the following best practices are recommended:

First, clearly distinguish service types. Use Type=simple with template units for independent processes requiring long-term operation; consider Type=oneshot for one-time initialization tasks.

Second, design parameter passing mechanisms appropriately. Ensure template parameters clearly express differences between service instances, avoiding overly complex parameter combinations.

Third, consider service maintainability. When dealing with numerous services, establish clear naming conventions and service grouping strategies to facilitate subsequent management and monitoring.

Finally, evaluate configuration scalability. As business evolves, service configurations may require dynamic adjustments—choose configuration approaches that support flexible expansion.

Conclusion

Systemd provides multiple configuration methods for achieving multi-process startup, each with its applicable scenarios and advantages. Template units suit parameterized service instance creation, target dependencies work well for service group management, and configuration management tools offer more advanced automation capabilities.

In practical applications, developers should select the most appropriate configuration approach based on specific requirements, balancing configuration complexity, management convenience, and system performance. By properly leveraging Systemd's features, efficient and easily maintainable service architectures can be constructed.