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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130522203904.ga7...@alf.mars
