[Soc-coordination] Report 3 - SysV-init file creator from systemd service files

akhil vij akhil.iiit at gmail.com
Sun Jul 1 15:30:07 UTC 2012

Hi Everyone,

Please find my third report below.

Third Report

Project - Sys-V init file creator from systemd service files

Status of the project so far :

In the last fortnight, I mostly worked on the conversion logic to convert
the options available under the [Unit] and [Service] section of a systemd
service configuration file. I went through the man pages of the systemd
'Unit' section[0] and 'Service' section[1] and had look at all the
available options. Then option by option, I went about converting them to
SysV init format (or bash commands). Here is a list of important options
(section-wise) with a short description and their corresponding conversion
logic which were done in the past few days :

Note : Now, in order to generate generic and widely accepted scripts, I
decided to follow the LSB convention[2] as much as possible. This idea was
discussed with the mentors and it results in the generated Sys-V files
being shorter and more compact and easy to manage. There was also certain
doubts I had with regard to LSB compliance which I discussed with the
mentors and managed to clear.

[Unit] Section

The options under this section are mostly used to generate the LSB header
in the created Sys-V init file. The main goal is to translate all the
requires and dependencies properly into the LSB header. Obtaining a correct
LSB header is very important because the order in which the Sys-V init
scripts are run by the init system is encoded in the LSB header. Options
with their conversion logic :

REQUIRES : This option is to configure the requirement dependencies on
other services. This is a hard dependency. Even if any one of the services
listed under this option fails for some reason, the whole transaction is
considered failed.
Conversion : This option maps directly to the Required-Start keyword of the
LSB header.

WANTS : This is a weaker version of Requires. Even if any one of the
services listed under this option fails for some reason, the whole
transaction is not considered failed.
Conversion : This option maps directly to the Should-Start keyword of the
LSB header.

REQUIRESOVERRIDABLE :  If executed during system start-up then this is
similar to the Requires option. If it is run by a user (using systemctl)
then its behaviour is like Wants option.
Conversion : Follows the same as Requires/Wants.

REQUISITE : Similar as Requires, but the services listed under this option
must be up else the transaction fails. Whereas in Requires, the services
listed would be started if they are not up.
Conversion : This option maps to Required-Start keyword and we have a
script for checking whether the listed services are up or not. We abort in
case the check fails.

CONFLICTS : The services listed here will be stopped if the this service is
Conversion : Script for checking and stopping the services listed  and we
use the standard killproc() and start-stop-daemon() defined in the
/lib/lsb/init-functions to achieve that .

BEFORE, AFTER : These options configure the ordering dependencies between
the services.
Conversion : These map to the Required-Start keyword.

These are the main options under the [Unit] section. There are other
options too like OnFailure, OnFailureIsolate etc. but these options are
related to the service monitoring feature of systemd and are not useful for
the generation of Sys-V init scripts.

[Service] Section

The service specific configuration options are configured in the [Service]
section. This section carries information about the service and the process
it supervises.
List of options with short description and possible conversion logic :-

PIDFile : Takes an absolute filename pointing to the PID file of the
Conversion : Define an environment variable $pidfile (or any other name) in
the sysV script.

GuessMainPID : Takes a boolean value that specifies whether systemd should
try to guess the main PID of a service.Usually ignored if explicitly
configured PID file is known.
Conversion : We use the pidofproc() method defined in the standard
/lib/lsb/init-functions to get the PID if the PID file is not known

ExecStart : Takes a command line that is executed when this service shall
be started up. It is mandatory that each service file has this option.
Conversion : Using the start_daemon() method defined in the standard
/lib/lsb/init-functions to execute the argument provided with ExecStart

ExecStartPre/Post : Additional commands that are executed before/after the
command in ExecStart option.
Conversion : Script to save all the commands in a list and then execute
them using the start_daemon() method.

ExecStop : Takes commands to execute to stop the service started via
ExecStart option. This option is not mandatory.
Conversion :  If the option is present, then simply execute the command
listed there. The problem comes when this option is not present. In such a
case, I identify the executable path from the ExecStart option and use
killproc() method in the standard /lib/lsb/init-functions to kill the job.

Future Plans :

There are still some options left in the [Service] section for which I need
to design the conversion logic. This week I intend to have a look at the
options available in the [Install] section and designing a conversion logic
for them. The code is present in my git repository[3]. The main aim is to
finish the major options present in the [Service] and [Install] section and
have a initial version of the conversion tool ready before the mid-term
evaluations (before 9th july). The testing will go on parallely with major
debian systemd service configuration files.

[0] : http://0pointer.de/public/systemd-man/systemd.unit.html
[1] : http://0pointer.de/public/systemd-man/systemd.service.html
[2] :
[3] : https://github.com/akhilvij/systemd-to-sysvinit-converter

Kind Regards,
Akhil Vij
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/soc-coordination/attachments/20120701/9df65b80/attachment.html>

More information about the Soc-coordination mailing list