Report 6 - SysV-init file creator from systemd service files

<div>
<div>Hi Everyone,&nbsp;</div>
<div>Please find my sixth and final report.</div>
<div><br></div>
<div>Sixth and Final Report</div>
<div>================</div>
<div><br></div>
<div>Project - Sys-V init file creator from systemd service files</div>

<div>==========================================</div>
<div><br></div>
<div>
<span>	</span>The last few days were dedicated to testing the converter, bug fixes and some documentation. I tested the script with major systemd service files shipped with Debian wheezy. I was able to manually control most of the services (start, stop, restart etc.) with the help of my generated SysV init script. There were some issues which I ran into while testing. These issues were documented, discussed with the mentors and most of them have been solved. Some issues still remain but these are mostly in cases where the systemd service file uses commands (especially in ExecStart/Stop etc.) which are not compatible with /lib/lsb/init-functions.&nbsp;</div>

<div><br></div>
<div>Major Issues faced:</div>
<div>-----------------------------</div>
<div><br></div>
<div>
<span>	</span>Some packages don't run as daemon when executed and the "service &lt;package&gt; start" command does not return to shell. This is because the "start_daemon" defined in lsb init-functions doesn't use "--background" arg while calling start-stop-daemon. Similarly, a small change was required in "killproc" lsb function too. First, I decided to modify the /lib/lsb/init-functions and create a converter.d directory in the src tree and include the modified version of the /lib/lsb/init-functions file in it (I thought we need this modified version, since I cannot force changes into the original /lib/lsb/init-functions file). But after more testing and discussion with the mentors, I realized that using "--background" in start-stop-daemon is not the correct thing to do. It isn't able to judge the correct execution status of the service once it forces the executable to go to background through fork(). So, I decided to go with the default init-functions. While continuing testing with the default init-functions, it seemed that the issue is with the ExecStart mentioned in the .service files. The ones which remain in the foreground are explicitly asked to do so(by {passing/not passing} an argument during execution). Note that, the respective sysvinit scripts provided by these packages don't use "--background" either. In my opinion, this isn't an issue for the converter. Config file author/admin should write the correct commands.</div>

<div><br></div>
<div>
<span>	</span>There was also an issue regarding the .ini file standard used by systemd. ConfigParser was not able to parse the ExecStart/Stop/Reload statements with multiple arguments separated by " ; ". This issue was also discussed with the mentors and has been solved. Also, there were many small bugs/issues which came up while testing and I have resolved most of them and updated the code in my repository[1]. Now the converter is able to generate a very basic and a clean init script for most of the packages under wheezy which support systemd. And I am able to control the execution of these services using the generated init script.</div>

<div><br></div>
<div>
<span>	</span>I have also sent a pre-release mail to the debian developer mailing list [0], asking for the feedback from other developers. I am getting useful feedback from them which is helping me to add more features, resolve some issues and make the converter more robust. Currently, I am having a discussion with the mentors on how to integrate my tool to the Debian packaging workflow, so that many more people could use it.</div>

<div><br></div>
<div>Summary of what I did and achieved</div>
<div>----------------------------------</div>
<div><br></div>
<div>
<span>	</span>Systemd is a replacement to the old SysV init system. It minimizes the boot time by parallelizing the initiation of most of the processes .Init scripts usually are very tedious, long, complex and hard to manage. On the other hand, systemd service files are short, easily managable and simple to write/understand. The goal of my project was to build a converter tool which when fed a Systemd script yields a SysVinit one. I was able to achieve this and generate quite correct, much more clean and simple init scripts. The long term aim of this project is to begin a slow but smooth migration of SysV-init to Systemd in Debian. The advantages of this converter tool are many, now the package developer will only have to maintain one systemd service file (which is easy to write/maintain) instead of both systemd and an init script, also basic &amp; simple generated init scripts will lead to a huge reduction in code duplication currently happening in the SysV init scripts.</div>

<div><span>	</span></div>
<div>
<span>	</span>I am quite satisfied with what I did and the project went successfully according to its initial plan, although there were some minor hiccups along the way. Also, the project (especially the testing and bug-fixing part) will continue after the GSOC's pencil-down date as more and more debian packages adopt to systemd. I have no issues with this as I would like to be a part of debian community and keep contributing for a long time to come :) .&nbsp;</div>

<div><br></div>
<div>[0] : <a href="http://lists.debian.org/debian-devel/2012/08/msg00433.html" target="_blank">http://lists.debian.org/debian-devel/2012/08/msg00433.html</a>&nbsp;</div>
<div>[1] : <a href="https://github.com/akhilvij/systemd-to-sysvinit-converter" target="_blank">https://github.com/akhilvij/systemd-to-sysvinit-converter</a>
</div>
<div><br></div>
<div>Kind Regards,</div>
<div>Akhil Vij</div>
<div><br></div>
</div>