I am currently pursuing my MS in computer science from IIIT-Hyderabad. My thesis is in the field of Security and Biometrics. I've been working on linux for the past 4 years. As part of my Bachelor projects I've gained plenty of experience with linux system programming and administration.

I've been the system administrator of my lab for the past 2 years and have been maintaining a linux cluster, based on CentOS. After the release of Fedora 16, I got interested in systemd and have been following the project since then

Projec Title: SysV-init file creator from systemd service files

Project Description:

systemd is a replacement to the good old sysVinit program. It minimizes the boot time by parallelizing the initiation of most of the processes.

This project demands a tool which when fed a systemd script yields a sysVinit one. The primary aim would be to convert the scripts into LSBinit scripts format.

As per LSB compliance, the scripts will have appropriate header elements and should at least implement the following functions - start, stop, restart, force-reload and status.

There are various tools available to convert sysVinit script to Systemd but this is probably the first attempt to do it the other way. It will take a good amount of effort, hacking and even a little trial/error to come up with almost perfect scripts after conversion.

Now, I'll convey my approach and understanding followed by a small demonstration.

Most of the LSB headers can be derived from their systemd counterparts. Here is a small table relating them.

P.S. - These relations are far from perfect. I'm mentioning them to convey my initial approach to the project. It'll certainly improve during summer.

Required-[start|stop] - These LSB parameters are primarily used for dependency based boot sequencing and they correspond to the [unit] section's Requires and After/Before parameters.

Should-[start|stop] - Should is a weak link dependency, i.e. the service listed if started/stopped its well and good, but if it fails it won't fail the whole transaction. This can be related to the "Wants" parameter.

Default-start - This option lists the default run level in which the service will be enabled. This is related to the ?WantedBy parameter os [Install] section. We'll have to filter only for *.target units, e.g. multi-user.target(similar to runlevel 3) or graphical.target(runlevel 5).

In a similar way, certain options of systemd will assist us in deciding the actions on starting/stopping the service. Some notable ones are:

?ExecStart - This shows the command that is going to be executed on the start() routine.

?ExecStart[Pre|Post] - The actions to be taken before/after the invocation of ?ExecStart.

Exec[Reload|Stop] - Actions taken in the reload() and stop() routine respectively.

Also - It mentions additional units(services) to be enabled when this unit is enabled.

Lets take the example of sendmail in Fedora 16(systemd) and 14(sysVinit). Here is how the systemd file looks like.

So, it is dependent on network services and syslog. There is a weak dependency on sm-client and the "Also" parameter shows that sm-client should be started along with sendmail. ?WantedBy mentions the default runlevel and Exec* set of statements define the actions to be taken on various calls - start, stop etc. To list out, we can gather the following LSB headers from the .service file.

All the normal system services are only started when the local file system is available, hence the $local_fs facility. Runlevel 5, graphical bootup, is an obvious superset of the console only boot, hence the service is set to start in this runlevel too.

Here is the original. If you compare, our script was quite close. Working with multiple scripts will definitely refine the conversion.

Synopsis: This project aims to provide a smooth migration from old sys-v-init to the new systemd using a tool which will convert systemd scripts into sys-v-init format. This will ensure that maintainers only have to maintain one file, thus easing the job for them.

Benefits to Debian: The benefits of systemd over sys-v-init and its alternatives are very clear and its being adopted as the default program by many major distributions - Fedora and ?OpenSuse. Changes in debian take time but they can't overlook the usefulness of systemd - the features and boot speed gain. Its very important for a distribution like Debian to make use of these features. Hence this project, aiming to begin a slow but smooth migration of sys-v-init to systemd in Debian.

Deliverables:

a tool that, given a systemd service file will output the corresponding init script implementing the corresponding commands/settings; a document or policy describing the limitations of the init scripts and service files; a huge reduction in code duplication currently happening in the SysV init scripts;

Schedule:

23rd April - 7th May - Talk to the community regarding the requirements and their inputs. Learn about the systemd integration efforts in Debian.

8th May - 21st May - Study systemd - both the adminstrative and working aspect. This will help in creating more parameter relations which could improve the conversion.

22nd May - 21nd June - Come up with a basic conversion tool(in Python).

22nd June - 15th July - Test the software on scripts of major services in Debian and keep improving it.

Mid Term Evalution - I plan to have the basic version of the tool working by now which would be able to correctly generate sys-v-init script for most services.

16th July - 7th August - I'll create a public repository and ask admins to use it and provide feedback. This period will primarily involve bug fixing.