Several systemctl commands work with unit files in the background.
To make finer adjustments, system administrator must edit or create unit files manually.
unit_name.type_extension
unit_name - Name of the Unit file
type_extension - Type of the Unit file eg service,socket,target etc
Understanding the Unit File Structure
Unit files typically consist of three sections:
[Unit] — contains generic options that are not dependent on the type of the unit. These options provide unit description, specify the unit's behavior, and set dependencies to other units.
[unit type] — if a unit has type-specific directives, these are grouped under a section named after the unit type.
For example, service unit files contain the [Service] section
[Install] — contains information about unit installation used by systemctl enable and disable commands
Example
The following procedure describes the general process of creating a custom service
type_extension - Type of the Unit file eg service,socket,target etc
Understanding the Unit File Structure
Unit files typically consist of three sections:
[Unit] — contains generic options that are not dependent on the type of the unit. These options provide unit description, specify the unit's behavior, and set dependencies to other units.
[unit type] — if a unit has type-specific directives, these are grouped under a section named after the unit type.
For example, service unit files contain the [Service] section
[Install] — contains information about unit installation used by systemctl enable and disable commands
Example
[root@server1 ~]# systemctl cat postfix.service # /usr/lib/systemd/system/postfix.service [Unit] Description=Postfix Mail Transport Agent After=syslog.target network.target Conflicts=sendmail.service exim.service [Service] Type=forking PIDFile=/var/spool/postfix/pid/master.pid EnvironmentFile=-/etc/sysconfig/network ExecStartPre=-/usr/libexec/postfix/aliasesdb ExecStartPre=-/usr/libexec/postfix/chroot-update ExecStart=/usr/sbin/postfix start ExecReload=/usr/sbin/postfix reload ExecStop=/usr/sbin/postfix stop [Install] WantedBy=multi-user.target
Important
[Unit] section option
Options
|
Description
|
Description
|
A meaningful description of the
unit. This text is displayed for example in the output of the systemctl status command.
|
Documentation
|
Provides a list of URIs referencing documentation for
the unit.
|
Defines the order in which units are started. The unit
starts only after the units specified in After are active. Unlike Requires, After does not
explicitly activate the specified units. The Before option has the opposite
functionality to After.
|
|
Requires
|
Configures dependencies on other units. The units listed
in Requires are
activated together with the unit. If any of the required units fail to start,
the unit is not activated.
|
Wants
|
Configures weaker dependencies than Requires. If any of
the listed units does not start successfully, it has no impact on the unit
activation. This is the recommended way to establish custom unit
dependencies.
|
Conflicts
|
Configures negative dependencies, an opposite to Requires.
|
systemd.unit(5) to see complete list of
unit options
[b] In most cases, it
is sufficient to set only the ordering dependencies with After and Before unit
file options. If you also set a requirement dependency with Wants (recommended)
or Requires, the ordering dependency still needs to be specified. That
is because ordering and requirement dependencies work independently from each
other.
|
|
Important [Service] Section options
Options
|
Description
|
Type
|
Configures the unit process startup type that affects
the functionality of ExecStart and
related options. One of:
·
simple –
The default value. The process started with ExecStart is the main process of the service.
·
forking –
The process started with ExecStart spawns
a child process that becomes the main process of the service. The parent
process exits when the startup is complete.
·
oneshot –
This type is similar to simple,
but the process exits before starting consequent units.
·
dbus –
This type is similar to simple,
but consequent units are started only after the main process gains a D-Bus
name.
·
notify –
This type is similar to simple,
but consequent units are started only after a notification message is sent
via the sd_notify() function.
·
idle –
similar to simple,
the actual execution of the service binary is delayed until all jobs are
finished, which avoids mixing the status output with shell output of
services.
|
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. Type=oneshot enables
specifying multiple custom commands that are then executed sequentially.
|
ExecStop
|
Specifies commands or scripts to
be executed when the unit is stopped.
|
ExecReload
|
Specifies commands or scripts to
be executed when the unit is reloaded.
|
Restart
|
With this option enabled, the
service is restarted after its process exits, with the exception of a clean
stop by the systemctl command.
|
RemainAfterExit
|
If set to True, the service is
considered active even when all its processes exited. Default value is False.
This option is especially useful if Type=oneshot is configured.
|
[a] For a complete list of
options configurable in the [Service] section, see the systemd.service(5) manual
page.
|
|
Important [install]
options
Options
|
Description
|
Alias
|
Provides a space-separated list of additional names for
the unit. Most systemctl commands,
excluding systemctl
enable, can use aliases instead of the actual unit name.
|
RequiredBy
|
A list of units that depend on the unit. When this unit
is enabled, the units listed in RequiredBy gain
a Require dependency
on the unit.
|
WantedBy
|
A list of units that weakly depend on the unit. When
this unit is enabled, the units listed in WantedBy gain a Want dependency on the unit.
|
Also
|
Specifies a list of units to be installed or
uninstalled along with the unit.
|
DefaultInstance
|
Limited to instantiated units, this option specifies
the default instance for which the unit is enabled.
|
[a] For a complete list of
options configurable in the [Install] section, see the systemd.unit(5) manual
page.
|
|
Creating Custom Unit Files
The following procedure describes the general process of creating a custom service
1. Prepare the executable file
2.Create the unit file
3.Configure the unit file with the required option
4.Notify the systemd using "systemctl daemon-reload'
1. Prepare the executable file
This can be a custom-created script, or an executable delivered by a software provider.
2.Create the unit file
Create a unit file in the /etc/systemd/system/ directory and make sure it has correct file permissions. Execute as root:
touch /etc/systemd/system/name.service
chmod 664 /etc/systemd/system/name.service
Note that file does not need to be executable.
3.Configure the unit file with the required option
Add the service configuration options. There is a variety of options that can be used depending on the type of service you wish to create,
The following is an example unit configuration for a network-related service:
[Unit]
Description=service_description
After=network.target
[Service]
ExecStart=path_to_executable
Type=forking
PIDFile=path_to_pidfile
[Install]
WantedBy=default.target
Where:
- service_description is an informative description that is displayed in journal log files and in the output of the systemctl status command.
- the After setting ensures that the service is started only after the network is running. Add a space-separated list of other relevant services or targets.
- path_to_executable stands for the path to the actual service executable.
- Type=forking is used for daemons that make the fork system call. The main process of the service is created with the PID specified in path_to_pidfile. Find other startup types in Table 10.10, “Important [Service] Section Options”.
- WantedBy states the target or targets that the service should be started under. Think of these targets as of a replacement of the older concept of runlevels.
4.Notify the systemd using "systemctl daemon-reload"
Notify systemd that a new name.service file exists by executing the following command as root:
systemctl daemon-reload
systemctl start name.service
Click the below link which show how to create a secondary SSHD service .
No comments:
Post a Comment