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)
NAME
upstart-socket-bridge - Bridge between Upstart and sockets
DESCRIPTION
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
this.
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/
slanga...@ubuntu.com vor...@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
task
script
: > "/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
signature.asc
Description: Digital signature
