Re: upstart: please update to latest upstream version
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.voipio@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
Reply to: