SystemD Service Scripts

This set of guidelines refers to the creation of a proper file for a Linux service with systemd. This kind of files/services are needed for all the CC7 system.

Services develop under/for systemd will be managed by Puppet, our configuration management and deployment tool.

Note We would like to remind you that is the author's responsibility to keep the scripts use by such services up-to-date, and this TWIKI is created to help you, so in case of feedback, please let us (SysAdmins) know.

So, let's develop this guide basing the instructions in a real example, like this request.

As a sub-detector expert (or developer,...) you are asked or need to execute a script in one or more of the machines in your group/task.

  • Such a script can be
    • the automatic start of an application
    • the execution of a series of bash commands (script) that allows the collection/analysis of some logs,
    • ...any other case where an application needs to be active, be restarted in case of a failure (unexpected exit) and even survive server restarts.

It's here where systemd comes into play: Systemd (from RedHat docs) is a system and service manager for Linux operating systems.

  • It is designed to be backwards compatible with SysV init scripts, and provides several features such as parallel startup of system services at boot time, on-demand activation of daemons, or dependency-based service control logic.
  • Systemd introduces the concept of systemd units. These units are represented by unit configuration files and encapsulate information about system services, listening sockets, and other objects that are relevant to the init system.
  • In Red Hat Enterprise Linux 7, systemd replaces Upstart as the default init system.

Create and Modify a systemd Unit File

From the documentation: "Service units end with the .service file extension and serve a similar purpose as init scripts."

So, let's create a file called applicationx.service

A template to start can be like this: (any text between parenthesis is a comment of what should be included and/or what that particular line is doing)

## Managed by Puppet ##

## (include here a one-line description of the function of this service)
Description=applicationx runs software X
## (the parameters after the = must include services that have to be ready before this service starts, so it means that this service must start after that set of services if that is the case)
After=autofs.service network.service det.mount

## ("Type" parameter configures the unit process startup type that affects the functionality of ExecStart and related options. Most common values are "simple" or "oneshot")
## (set the proper path to your script, please see note on "ExecStart later on")
ExecStart=/det/xxx/yyy/zzz/applicationx start

## (This corresponds to multi user mode with networking)

As you can see, this is a simple file that will define the way the service will interact with the system and under which circumstances must be started.

Note on ExecStart parameter: We strongly suggest you not to use wrappers. They tend to be difficult to debug and can hide operations that in most of the cases can be simplified.

So, try to add the most direct way to execute the application that you really need. This could mean to call the executable of the application directly.

  • Be aware that you can define multiple commands using ExecStart. From the RedHat documentation (Table 10.10 and Example 10.17)
    • ExecStart Specifies commands or scripts to be executed when the unit is started. ExecStartPre and ExecStartPost specify custom commands to be executed before and after ExecStart....

Once again, for more options and explanation, refer to the documentation.

Regarding the (your) script

Systemd will check the output of your script to evaluate if the service execution was successful or not.

This makes it extremely important that your script produces the correct exit values for the right status.

  • A typical example is that a service manages by Puppet will be restarted if the exit code is different than 0. This tends to create issues because Puppet is executed periodically in each machine every 30 min (netbooted) or 60 min (local boot).

Test your script and be sure that

  • it works as intended
  • it has the right paths (relative versus absolute paths, etc...)
  • its exit code(s) is(are) correct
  • It is not using test apps or custom tools that are not in the production system.

Getting your new service in place

Once you define your script (including the correct exit values) and unit file, open a RedMine ticket
  • Describe the case: what is the script doing, and any other information you find relevant (e.g. is this a service that most start at boot time?...)
  • Because Unit file tends to be short, there is no need to attach any file; you can simply paste the text in the ticket. We will help you to get to the final configuration.

Web references

-- arturos - 2020-04-13

Edit | Attach | Watch | Print version | History: r2 < r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r2 - 2020-04-17 - ArturoS
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    Main All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2020 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback