On Mon, Feb 27, 2012 at 12:24:25PM +0200, Riku Voipio wrote: > On Fri, Feb 24, 2012 at 01:47:59AM -0800, Steve Langasek wrote: > > > I have. Not on debian, but on debianish system with dash. And the result > > > was that shellscripts are indeed the bottleneck. We still did convert to > > > upstart since we believed it would allow us to cut down the amount of > > > shell scripts. The event based architecture however forced much more > > > shell scripting[1] that made the boot time improvement much less than > > > hoped.
> > Interesting to know, thanks. Was this done in a head-to-head comparison > > with the systemd "no shell" boot? > Systemd was not at ready that time.. Every exec has a price, and if a > upstart stanza has a pre-start and post-start script, that is already two > shell execs. Any command in shell script that is not a shell builtin is > more execs. In this sense dash is worse, as it has less builtins that > bash. for example sleep is not a builtin... No disagreement with any of that. But how high is that price, in point of fact? If no one's measured it, then converting scripts to C programs to avoid the added exec() calls is premature optimization. If the only comparison is between two different distros, you might find that your boot time is higher for completely unrelated reasons (bug in a video driver? handling of corner cases in one path but not the other, that impact the reliability for that 1% of users it matters to?). 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. > 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? > > If you have other stuff *like* this, I'd be interested to see it. That > > particular upstart job is needed only because of peculiarities of how cups > > starts up. > > Well that was a common development idiom with upstart when our developers > realized that neither "on started" or "on starting" did what they > wanted... Some of them were got rid of by changing upstream code to emit > a signal when really ready. Right, this requires a definition of "started" that's appropriate for the service in question. Socket-based activation would be another solution here, but that might also require changing upstream code anyway. FWIW, aside from this one bug affecting cups, I'm pretty sure that *any* service for which upstart's "on started" is broken/racy is also broken/racy in sysvinit. The code really ought to be fixed upstream for everyone's benefit. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
