Re: systemd .service file conversion
On Wed, May 22, 2013 at 10:39:06PM +0200, Helmut Grohne wrote:
> 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.
Note that such conversion to a sysv init script is not supposed to
provide all the features that upstart and systemd provide. Else
there would be no need to move to systemd or upstart in the first
place.
> * stdout/stderr to syslog redirection
> This is possibly implementable, but needs more than a line of shell.
Do you know about logger(1)? If that itself is not good enough,
it should be easy enough to make something that does what you
want.
> * 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.
It's not because it's not needed that we can't add this. If we
already have this information there is no need to throw it away.
> * 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.
That would just mean that those don't work at all with sysv
anymore, and since I think we still have to support sysv,
we should fix them.
> 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)?
I would argue that if such a conversion script would exist, we can
probably have more consistent init script implementations, and
less bugs in them.
I'm also not sure why fixing a conversion script is that much
work.
Plsese note that I'm not saying that such a script is a good or
bad thing, just that I don't follow your arguments.
Kurt
Reply to: