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

Re: upstart: please update to latest upstream version

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)

       upstart-socket-bridge - Bridge between Upstart and sockets

       The  upstart-socket-bridge  queries  the Upstart init(8) daemon for all
       job configurations which start on or stop on the socket event. It  then
       waits  for  an incoming connection on each specified socket(7) and when
       detected emits the socket event (socket-event (7)), setting a number of
       environment variables for the job to query.

Upstart supports socket-based activation just fine.  However, there appear
to be a grand total of 0 packages in Ubuntu currently making use of this, in
part because most services require *modifications to upstream code* to
support socket-based activation.  inetd just is not the dominant paradigm in
service design anymore; so all those services out there that don't support
passing their socket in as an fd on startup would have to be updated to use

The other reason for packages not making use of this in Ubuntu seems to be
that nothing is actually missing it.  Yes, it allows deferred startup of
services that aren't needed as part of boot to desktop, but by and large
this is a bandaid for a more fundamental problem of having servers installed
on your desktop that shouldn't be; and Ubuntu addresses this by just not
shipping unneeded services on the desktop.  For the server case,
socket-based activation isn't better, because these jobs *are* the critical
pieces of the boot and waiting until the first request comes in to start
them (and thus having a slow response to that first request) is not
beneficial.  And for the edge case of deliberately installing and running
servers on the desktop, well, you have to pick your poison, because neither
approach is going to be a perfect fit for everyone.

> 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.

> > 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.

> 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.

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/
slangasek@ubuntu.com                                     vorlon@debian.org
# mounted-run - Populate and link to /run filesystem
# Populates the /run filesystem and adds compatibility links to it

description	"Populate and link to /run filesystem"

start on mounted MOUNTPOINT=/run TYPE=tmpfs


    : > "/run/utmp"
    chmod 664 "/run/utmp"
    chgrp utmp "/run/utmp"

    # compatibility; should go away soon
    [ -d /dev/.initramfs/varrun ] && cp -a /dev/.initramfs/varrun/* /run/ || true

    mkdir -p /run/sendsigs.omit.d

    # Background the initial motd seeding
    [ -d "/etc/update-motd.d" ] && run-parts --lsbsysinit /etc/update-motd.d > /run/motd &
end script

Attachment: signature.asc
Description: Digital signature

Reply to: