Maybe interesting to read in this upstart vs. systemd vs. sysvinit discussion is the comparison of these three init systems: http://0pointer.de/blog/projects/why.html Of course, Lennart Poettering did this, but the points mentioned are valid. (Although the list is a bit outdated, at least on upstart's side) Cheers, Matthias Klumpp
2012/2/27 Riku Voipio <riku.voi...@iki.fi>: > 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... > > 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. > >> > [1] stuff like this: >> >> > -snip- >> > post-start script >> > # wait until daemon is ready >> > timeout=6 >> > while [ ! -e /var/run/cups/cups.sock ]; do >> > sleep 0.5 >> > timeout=$((timeout-1)) >> > -snip- >> >> Oh dear, you've managed to find the worst upstart job in Ubuntu ;) > >> 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. > > I just grepped an Ubuntu system to see if there were similar cases in Ubuntu > as well ;) > > Riku -- 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/CAKNHny_-o+tT2ShAvJxts63gi5L_i=qb8mqxtr-prheg2fj...@mail.gmail.com