[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: upstart: please update to latest upstream version



On Feb 21, 2012, at 11:22 PM, Steve Langasek wrote:

> On Tue, Feb 21, 2012 at 10:28:55PM +0100, John Paul Adrian Glaubitz wrote:
>>> What do you know of the upstart design that makes you think systemd's design
>>> is better?  The above could be a paraphrase of Lennart's blog, for all it
>>> says about the upstart design.
> 
>> Socket-based activation.
> 
> upstart-socket-bridge(8)                               upstart-socket-bridge(8)

That's nice, I didn't know that. Today I learned!

>> It just seems to be the proper way to do it. Not depending
>> on a bunch of bash scripts to do the proper dependency resolving
> 
> Strawman.  Upstart doesn't use bash scripts, nor are scripts at all involved
> in dependency resolution.

Well, the file you attached looks like a script to me. Doesn't have to be
bash, but it still seems to be a script which forks a lot of sub processes.

>>> The meme that systemd is better than upstart because it doesn't depend on
>>> a shell is poppycock.  No one has done any benchmarking to support the claim
>>> that /bin/sh is a bottleneck for upstart (particularly not on Debian or
>>> Ubuntu, where /bin/sh is dash, not bash);
> 
>> That is probably true. But I still think that a more consistent and strict
>> software design is better. The boot process is in most cases more or
>> less the same,
> 
> That's a gross oversimplification.

That boot processes are the same, most of the time?

> 
>> so why not make the init system smarter to simplify the
>> scripts/configuration files on the user side?
> 
> Please tell me why it would be better to implement the attached upstart job
> in C code within pid 1.

Well, in systemd, the init daemon itself cares about the mount points, not
user-defined scripts. I have tested it in a corporate environment (200 clients)
with NFS shares and auto mounts and I really appreciate the fact that there is some
daemon which reliably takes care of the mounts and guarantees they
get mounted when a user is trying to access a folder, no matter what.

It's not unusual for NFS mounts to fail to mount during startup due to
race conditions, so users would end up without their home directory
after a reboot from time to time. It's quite nice to have systemd take care
of that.

Don't get me wrong, my intention is not to diminish upstart in any way.
I'm just saying that I think that systemd is in my opinion the best
solution and the fact that many distributions are adopting it seems
to speak for that.

I don't want anyone to tell what init system to use, each of them has their
pros and cons. That's why I said I would support keeping upstart in
Debian in my previous messages. Just leave the choice to the user :).

The biggest disadvantage of systemd is surely that it is Linux-only and
probably won't work with other kernels in near future, so it's absolutely
desirable to support several init systems in Debian.

Adrian

Reply to: