Re: upstart: please update to latest upstream version
On Sat, Feb 25, 2012 at 1:00 AM, Russ Allbery <rra@debian.org> wrote:
> Steve Langasek <vorlon@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,
Reply to: