systemd .service file conversion
On Tue, May 21, 2013 at 10:53:43PM +0200, Lucas Nussbaum wrote:
> There was a GSoC project in 2012 about generating sysvinit scripts from
> systemd .service files. Was there some communication about its outcome?
I had a look at this idea and its result. From what I saw, I do not
believe a conversion process to be successful in a big enough fraction
of actual .service files. This is because systemd (and for that matter
upstart should we consider a job file conversion as well) actually
provide more functionality than sysv does. Some of that functionality
does not properly map to an init script conversion.
* stdout/stderr to syslog redirection
This is possibly implementable, but needs more than a line of shell.
* supervision/service restart/heartbeat
sysv simply does not provide this functionality. Other tools are
needed to mimic this. An option could be djb's daemontools. Still you
either end up with some supervision process with similar tasks as
systemd/upstart or have a supervision process per service.
* missing dependencies
Due to the use of socket activation it is to be expected that
services stop declaring their dependencies. In .service files this
information commonly is not present, because it is not needed.
* socket activation cont'd
I guess that at some point services will expect that their sockets
are already open when they are started, because this eliminates a
privileged bind() operation.
* resource/privilege limitations
Service files provide a mechanism to describe and limit the required
privileges or resources. Some of these map to shell commands, others
don't. Arguably this part is non-essential to a conversion process.
You can already see parts of these in action in current .service files,
but it is to be expected that there will be more usage of these and
other features.
> Is it realistic to dream about a generator that would automate the
> generation of sysvinit scripts, systemd .service files, and upstart job
> files for a majority of our packages (the "easy" ones)?
Based on the above arguments, I believe that a conversion process will
not work out. (I note that I may be wrong here.) Talking just about
systemd and sysvinit, there is the possibility to create a .service
interpreter to let sysvinit execute systemd .services. upstart already
has such an interpreter. The necessary hooks in sysvinit/insserv already
exist and are easily extensible. I therefore suggest to drop the idea of
generating shell scripts. Also consider the amount of work required to
fix a bug in a conversion utility compared to an interpreter. Are we
really gonna rebuild all services (that only ship a .service file)?
>From my point of view this raises the question of interoperability
between systemd and upstart. Is a conversion in either direction
feasible? Possibly systemd -> upstart, because we already have the job
interpreter?
Helmut
Reply to: