Re: systemd .service file conversion
On Thu, May 23, 2013 at 12:47:46AM +0200, Kurt Roeckx wrote:
> 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.
At least in case of systemd files, providing this information is often
unwanted. Ordering dependencies can be specified explictly using
Before= and After=, but if socket activation is used, services can be
started in parallel. If one of the services then attempts to query the
other, it'll hang (the kernel queues the packet) until the other
service starts processing requests. Declaring the dependency
explicitly doesn't gain anything, and can add an unnecessary slowdown.
It is just better to have the dependencies solved "automagically", and
adding explicit requirements for the sake of sysvinit conversions is
unlikely to be met with much enthusiasm.
> > * 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.
Providing a conversion script which recreates all of systemd
functionality would basically mean reimplemting a big part of
systemd in shell. Providing an interpeter would man reimplementing
a big part of systemd in whatever the interpreter is written in.
Both options seem infeasible, unless only partial functionality is
supported. [1] lists e.g. SystemCallFilter=, PrivateTmp=, PrivateNetwork=,
CapabilityBoundingSet=, SecuritBits= which have security and
correctness implications, and are IMHO pretty hard to recreate.
Zbyszek
[1] http://www.freedesktop.org/software/systemd/man/systemd.exec.html#Options
Reply to: