On Sat, Feb 25, 2012 at 1:00 AM, Russ Allbery <r...@debian.org> wrote: > Steve Langasek <vor...@debian.org> writes: > >> There are two main challenges here that I'm aware of with trying to >> generate init scripts from upstart jobs: > >> - Process supervision. A lot of the win of moving to an init system like >> upstart or systemd is that init *knows* which process corresponds to >> which job and doesn't have to use PID files. If we lose the process >> supervision, we have to manage how to generate PID files for our >> processes again, for all the different ways that daemons start, and we >> have to track that information somewhere - even if we put it in the >> upstart job or systemd ini, it's information not being used except under >> sysvinit, so have we actually saved ourselves from code rot? > >> - Dependency tracking. Upstart start conditions are not easily convertible >> into the kind of dependency information that's useful to >> insserv+startpar; with socket-based activation in systemd, much of the >> inter-service dependency information is missing altogether. Again, this >> is probably going to somehow require tracking information for the benefit >> of sysvinit that's not used by the native consumer of the job format. > >> Granted, though, it's at least potentially possible to keep track of >> both of these things in a declarative fashion, and there'd certainly be >> some benefit to that even if we're not entirely free of the risk of bit >> rot. If someone is interested in trying to implement such an upstart >> job -> init script autoconverter, I'd be willing to help. > > The nice thing about the converter is that, as people have pointed out > before, you don't have to solve the whole problem like you would if you > were writing a full init system. An 80% solution would be fine; the other > 20% of the software will require manually-written init scripts, and will > bear some maintenance burden, but they're probably also likely to be more > "core" software that's worth the additional work. > > The goal for the converter, I think, should be to get the typical daemon > that people are packaging without a huge amount of expertise to just work, > not to get, say, the complex system startup scripts to convert > automatically.
How about a converter from a different, init-agnostic format into the specific formats? That way we could specify stuff that's specific to each format, things such as: * Socket activation information for systemd (and possibly upstart with upstart-socket-bridge) * Events emitted by upstart * Dependencies declared in the LSB header of the sysvinit script * Path to the pidfile for the sysvinit script * Invocation for the sysvinit script so that the process stores the pidfile at the specific location This file could be easier to parse than a upstart/systemd unit too. I think even more than scripts could be converted into this basic format. The only drawback I can see is that it's another init description syntax to learn (if it's simple enough, maybe it's not a big deal). Lots of packages use /etc/default. I wonder if we could map a big chunk of those cases into this basic format, stuff like *_EXTRA_OPTS/*_OPTS. There's also *_DISABLED/*_ENABLED, which are redundant (since all init systems already provide a way to disable services), but which we might want to support too for backwards compatibility. Supporting this alone would mean even more packages can start using this basic format with no changes for end users at all. I guesstimate 90-95%. Then there's always oddball init scripts. I bet some of those can be fixed, some may be split into a wrapper script (which could also be invoked by upstart and systemd for even more reuse). I can envision this converter being plugged into dh so that the init files are automatically generated. The maintainer could supply init-specific scripts for weird stuff that isn't covered by the basic format supported by the generator. Regards, -- 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/canvyna_csn3ebasnb43j6tz4nwmebgntgyborl6mwxp4-72...@mail.gmail.com
