[systemd-devel] Improved systemd service configuration from LSB init scripts?

[Adam Spragg]

Hi there.

I was working on something earlier today which caused me to look at LSB init 
script headers, and it made me think of the systemd ability to use "legacy" 
LSB init scripts for "service" configuration, with the following query:

Does anyone think it would be useful to use the local extension facility 
provided by LSB[0] to add support for "X-systemd-*" keywords in existing init 
scripts?

That might give sysadmins/distros an easier way to configure, or provide an 
upgrade path to, systemd, while still maintaining sysv as an option/fallback. 
It could also head off inevitable bug reports from users who are not 
interested in systemd and do not have it installed, but nevertheless get 
systemd config files dropped about the place, because the daemon package will 
need to include/install them.

For example, taking the /etc/init.d/exim4 on my system, and the test1/mail-
transfer-agent.{service,socket} files in systemd, it could be possible to 
configure exim4 like so:

#! /bin/sh
#
### BEGIN INIT INFO
# Provides:          exim4
# Required-Start:    $remote_fs $syslog $named $network $time
# Required-Stop:     $remote_fs $syslog $named $network
# Should-Start:      postgresql mysql clamav-daemon greylist spamassassin
# Should-Stop:       postgresql mysql clamav-daemon greylist spamassassin
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: exim Mail Transport Agent
# Description:       exim is a Mail Transport agent
# X-systemd-service-ExecStart:      /usr/bin/postfix
# X-systemd-socket-ListenStream:    53333
# X-systemd-socket-ListenFIFO:      /tmp/systemd-postfix-fifo
### END INIT INFO
...

It just adds 3 lines to the current init script. It uses the existing LSB 
dependency information, instead of duplicating it (which is always a bad 
idea), and allows for incremental upgrades (e.g. if you started with just 
adding the "service-ExecStart" line, and left the socket config for later).

Would this make sense? Are there any problems with the idea? (Other than the 
matter of writing it ;-)  Or do the separate service/socket config files add 
enough extra configurability that this could get in the way of migrating to 
the native (better) solution?

Adam

[0] http://refspecs.freestandards.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-
generic/initscrcomconv.html