Re: upstart: please update to latest upstream version
Steve Langasek <vorlon@debian.org> writes:
> I would certainly welcome it if someone did profiling that showed whether
> the shells are a bottleneck. My own subjective experience is that this is
> probably not the low-hanging fruit on a general-purpose distro, but if it
> turns out that there are significant speed improvements to be had, we could
> certainly look at moving more core startup functionality into C for upstart.
Or compile shell scripts to binary. There are a number of toy compilers
for shell out there that could be adapted for that use.
>> The other factor of shell scripts is psychological. Since shell scripts are
>> so easy to modify, people tend to litter them with unneccesary checks,
>> settings, workarounds and other spagethi.
>
> One of the worst contributors to the use of 'script' in upstart jobs instead
> of 'exec' is the need for backwards-compatibility with pre-upstart
> /etc/default/* files. The options here are all fairly poor:
>
> - ignore the admin's /etc/default settings when switching init systems
> - migrate any local changes to /etc/default into the upstart job at upgrade
> time, by editing a conffile in a maintainer script
> - keep sourcing /etc/default at runtime
>
> I guess systemd has largely chosen option 1 (in part because there's a weird
> view in the systemd community that these jobs belong upstream, so Debian
> integration issues are entirely ignored). For many upstart jobs in Ubuntu,
> we've chosen option 3. Which do you think is the right solution? Are there
> other options I haven't seen?
Option 3 is the right solution.
Option 1 is just plain wrong. There are a number of packages where I've
had to change the defaults to suite my needs and all that work would be
lost.
Option 2 is also bad. There is a reason why we have /etc/default instead
of setting the options in the init.d scripts directly. Most importantly
the init.d scripts can be updated without dpkg questions.
MfG
Goswin
Reply to: