Re: upstart: please update to latest upstream version
Detailed replies below, but first of all, a quick top-level response,
because in my previous mail I missed mentioning an obvious point:
systemd can easily become the default for Debian GNU/*Linux* without
necessarily becoming the default for Debian GNU/kFreeBSD. This seems
like the most likely scenario going forward. Packages providing
services can then ship .service files (as they currently can), and can
ship init scripts if they want to run on other platforms; packages
satisfied with systemd's init script support and not interested in
providing a .service file can just ship an init script.
This effectively matches the status quo, with the sole difference that
systemd would get installed by default on Linux and sysvinit would
continue to get installed by default on kFreeBSD.
I assume that from a kFreeBSD perspective you have no particular problem
with that scenario? (I say "from a kFreeBSD perspective" to detach that
point from any thoughts you might have about the use of systemd on
Linux, which seem entirely orthogonal.) If so, I don't think we
disagree on anything, and feel free to simply ignore the rest of this
mail.
As an extension of that, I frequently wonder whether it would make more
sense to package daemons *without* init scripts or .service files or
anything else, and ship those in separate packages that you can install
*if* you want to run the default system-wide instance of those services,
rather than a custom-configured local service, twelve local instances,
per-user instances, or any other configuration you might want. Apache
already does this, with apache2.2-bin and apache2.2; git does the same
thing for git-daemon, with the git package shipping git-daemon, and
git-daemon-run and git-daemon-sysvinit packaging the init scripts for
different init systems. Personally, I'd love to see a split like that
for almost all daemon packages. Given such a split, the same people
don't necessarily need to maintain the -sysvinit or -systemd packages
that maintain the daemons themselves...
Feel free to ignore everything below this point if you agree with the
notion that "default for Linux" does not have to mean "default for all
Debian ports including non-Linux ports".
On Wed, Mar 07, 2012 at 10:12:49AM +0100, Wouter Verhelst wrote:
> On Tue, Mar 06, 2012 at 02:46:44PM -0800, Josh Triplett wrote:
> > Wouter Verhelst wrote:
> > > On Tue, Mar 06, 2012 at 02:08:00PM +0000, Jon Dowland wrote:
> > > > On Tue, Mar 06, 2012 at 10:12:43AM +0100, Wouter Verhelst wrote:
> > > > > But I do think that writing portable software isn't that hard, and that not
> > > > > doing it is pure lazyness.
> > > >
> > > > It's not about difficulty, systemd isn't not-portable simply because the
> > > > authors haven't got around to it yet; it fundamentally relies on a Linux-only
> > > > technology.
> > >
> > > This is wrong. An init implementation is not fundamentally Linux-only.
> > > No matter how they chose to implement it, no matter what they've ended
> > > up with, it is fundamentally possible to write an init implementation
> > > that will work on more than just Linux.
> >
> > You've said something entirely different here that doesn't refute the
> > point you replied to.
>
> I think it does.
>
> > systemd fundamentally relies on Linux-only technologies, because it
> > specifically provides access to those technologies, takes full
> > advantage of those technologies, and uses them to provide an init
> > system capable of doing things that sysvinit can't do. What you said
> > remains true: you *can* write an init implementation that will work on
> > more than just Linux, and sysvinit provides an existence proof backing
> > up your claim; that doesn't mean you can write systemd or an init
> > implementation with equivalent functionality,
>
> Yes you can.
>
> It's possible to write an init implementation in such a way that it
> provides more features on one architecture than on another. If there are
> daemons that fundamentally depend on the functionality that isn't
> available on non-Linux versions of systemd, then these daemons won't be
> able to work on non-Linux, but that would be the case anyway.
You've just moved the bug reports around, then; instead of reporting a
bug on systemd for not working on non-Linux, you'd report a bug on a
service for using a systemd feature that works on Linux. That seems
like a net loss: instead of having an init system with the explicit goal
of making the full functionality of Linux available to services, you
have a more complex init system whose featureset varies based on the
capabilities of the target platform, and services would have to cope
with that, generally by just not using any features other than the
lowest common denominator supported on all platforms. Given that this
thread exists in large part because people want those features, to make
services more reliable, easier to write, and easier to maintain, that
doesn't seem like a workable solution.
> > just that you can write a least-common-denominator init system as
> > capable as sysvinit. This thread exists in large part because many
> > people want an init system more capable than sysvinit.
> >
> > To give one particular example: systemd uses Linux-specific features to
> > accurately track all the processes started by a service, which allows
> > accurate monitoring and shutdown of processes which could otherwise
> > disassociate themselves from their parent processes via the usual
> > daemonizing trick.
>
> Yes, that's the cgroups feature.
Right.
> > POSIX doesn't provide features that allow this in general, but Linux
> > does. (Quite possibly other OSes provide those features too, but not
> > in a standardized way.)
>
> Indeed. That means there would need to be multiple implementations of
> the same functionality; one per supported OS. On some systems said
> functionality wouldn't be available, and that'd be fine; on others, it
> could behave slightly different in the undefined parts of the spec, and
> that would also be fine.
No, that's not fine. Systemd services use specific functionality with
the expectation that that functionality will work, not "kinda sorta
provide best effort if the platform can handle it", and certainly not
fail to work at all.
And if systemd did provide such inconsistent support, that would just
punt the bug reports from systemd ("doesn't work on $PLATFORM") to
services ("please don't use this feature in your service because it
doesn't work on $PLATFORM").
> Portability doesn't require you to limit yourself to POSIX, it just
> means you should have all functionality covered everywhere.
Same problem. Systemd specifically provides support and integration for
functionality only available on Linux. If you want portability, you
have to force people not to use those features, or to reimplement them,
at which point why do they exist in the first place?
To give just a few examples of functionality systemd provides (and
exposes to services) that uses Linux-specific features, and thus does
not fall under "all functionality covered everywhere":
- .device units and support for running a service once a device becomes
available (including via hotplugging).
- Support for giving a service a private network namespace, or no
networking at all. Likewise for other namespaces, such as filesystem
mount namespaces.
- CapabilityBoundingSet, and many other features relying on capabilities
- KillMode=control-group, and many other features relying on cgroups
- TTYVHangup, TTYVTDisallocate, and various other TTY features.
- Support for resource limits, including Linux-specific resource limits.
- OOMScoreAdjust
- PipeSize in socket-activated units, which uses the fcntl F_SETPIPE_SZ.
And that just represents the stuff I knew of off the top of my head; a
quick check of the systemd manpages turns up many more.
> If you can
> do that with POSIX, then do it with POSIX; if you can't, then you'll
> require #ifdefs or parallel implementations.
Or a new program for another target platform. Nobody expects LXC to
work on non-Linux platforms without Linux containers; other platforms
can implement container support and corresponding userspace tools.
> It also doesn't mean you
> have to do *everything* yourself, and it's perfectly acceptable to
> request that people who care about the architecture in question do the
> bits specific to that architecture. However, systemd upstream has
> expressed hostility to that concept, so I don't think it's going to
> happen.
systemd upstream has made it clear that they'd recommend implementation
of native init systems for other platforms, taking full advantage of the
features of those platforms.
> > > It is perfectly possible to make an init implementation that uses
> > > Linux-only technologies on Linux, but which falls back to a different
> > > mode on non-Linux. The reasl reason why systemd is Linux-only is because
> > > systemd upstream decided it would be easier to implement systemd that
> > > way, and because they didn't care about non-Linux. I find that to be
> > > lazyness; but that is, of course, their prerogative.
> >
> > You've got your cause and effect backward here. systemd specifically
> > provides access to Linux-only features to provide functionality it
> > couldn't otherwise provide. *Given* that systemd already needs
> > Linux-specific functionality, upstream figured that they might as well
> > continue using other Linux-specific functionality that makes things
> > easier, rather than writing everything to the lowest common denominator
> > of what a pile of OSes support.
>
> Again, portability doesn't have to imply you limit yourself to the lowest
> common denominator.
Yes, it does. To make the program itself portable, you can't build
functionality that relies on features only available on some platforms.
Presumably you wouldn't consider this acceptable portability:
#ifdef appropriate_symbol
linux_syscall_that_avoids_an_inherent_race_condition(...);
#else
#error Other platforms provide no way to implement this functionality securely.
#endif
(And writing the same code without the #ifdef and #error amounts to the
same thing, just with a different error message.)
And for programs like systemd which provide interfaces to other
software, even if you built those interfaces to only expose
functionality available on the target platform, you've just punted
portability to the next layer up: services can then only rely on the
features available on all platforms. Lowest common denominator.
systemd promises a given featureset to other software built on top of
it, and doesn't just leave out bits of that featureset depending on the
platform.
> > > At any rate, I think the only solution to the dilemma here would seem to
> > > be if someone were to port systemd to kFreeBSD. If neither the kFreeBSD
> > > people nor the systemd people are willing to work on that, then we can
> > > discuss and talk about this into eternity, but it will be highly
> > > unlikely that we'll ever arrive at a solution.
> >
> > You've missed several other possibilities here:
> >
> > - kFreeBSD implements a systemd-compatible init system that doesn't
> > necessarily represent a port of all of the systemd codebase. I
> > suspect that systemd wouldn't object to making a few library bits
> > portable, such as code parsing systemd service files, to allow sharing
> > that between implementations.
> >
> > - kFreeBSD implements kernel APIs compatible with the Linux APIs that
> > systemd requires, drastically reducing the amount of porting work
> > required, and turning it into a configuration problem. That would
> > benefit many more pieces of software, not just systemd. Note that
> > kFreeBSD has a huge headstart here, because it already uses glibc, and
> > thus doesn't need to worry about all the glibc-specific APIs. One of
> > systemd's major development tenets roughly amounts to "fix bugs, don't
> > work around them, even when those bugs live in the kernel (because we
> > can fix that too)"; that tenet represents a large part of systemd's
> > non-portability.
>
> These are definitely options, *if* someone can be found to do that. If
> not, I don't think systemd can expect to be the default init
> implementation in Debian. If systemd advocates want that, they should do
> the hard work themselves, and not inflict such work on the kFreeBSD
> developers.
So, if systemd had gotten packaged first, and Debian daemon packages had
all switched over to .service files and not init scripts, you'd find it
reasonable for systemd maintainers to say that kFreeBSD developers
should do the hard work themselves and not inflict such work on the
systemd maintainers? That doesn't seem acceptable either.
Regardless of the current status of either technology, I think we can
reasonably evaluate both kFreeBSD and systemd, consider to what extent
they can coexist, and to the extent they can't, consider what provides
users and developers with the most value. The same goes for any other
technical decision. Status quo does not automatically provide the
most value for users and developers.
> > - systemd continues to become more popular, and upstreams start
> > depending on it inherently and using systemd features that make it
> > non-trivial to write a simplistic init script with equivalent
> > functionality. Debian eventually finds the rug pulled out from under
> > it. See udev for a successful application of this strategy, with
> > exactly the same rationale: static /dev doesn't give you the
> > capabilities required to implement interesting functionality, such as
> > hotplug and event-driven device handling. Net result: Debian ends up
> > in the same place, but after inflicting sysvinit on people for much
> > longer.
>
> There's a difference.
>
> Udev was written so that some functionality which was statically defined
> in the kernel could be moved into userspace. As a result, today it's
> impossible to use Linux without udev if you want to be able to talk to a
> number of devices. The userspace bits that depend on udev are still
> replaceable, though I'll grant you that it gets harder as time moves on.
> So, what makes udev virtually required today is the kernel, not
> userspace.
udev doesn't just exist to move kernel functionality into userspace. In
fact, that part of its functionality (the ability to create devices
dynamically in response to hotplugging) no longer exists in udev, and
has moved back into the kernel in the form of devtmpfs. udev primarily
exists to expose Linux device events to userspace, and allow userspace
to wait on those events, extract information from those events, and
otherwise take action based on those events.
> Systemd isn't written to move functionality from the kernel to
> userspace; instead, it was written to replace one userspace interface by
> another. While it's possible that systemd may become the leading init
> implementation on Linux, it wouldn't be the case everywhere unless it
> gets ported; software that wants to be portable will have to support
> other init implementations anyway. So I doubt that it will ever become
> impossible to run a Linux system without systemd.
systemd, by design, exposes a large amount of Linux functionality to
userspace, so that userspace can make use of that functionality.
I didn't say it would become impossible to run a Linux system without
systemd; I suggested that upstreams will start relying on it. If more
upstreams start relying on features of systemd, and shipping .service
files rather than init scripts, Debian will end up with more and more
porting work to do, turning five-line .service files into hundred-line
init scripts with less functionality and less reliability.
In any case, I don't think we need to argue over that particular
scenario. Either it'll happen or it won't, and Debian will have little
to do with that either way.
> > > kFreeBSD is already part of Debian. Systemd is not. The answer would
> > > seem to be obvious.
> >
> > "First come, first served" does not inherently represent a sensible
> > problem-solving strategy, and in particular it has no ability to escape
> > local maxima.
>
> From our constitution:
>
> Nothing in this constitution imposes an obligation on anyone to
> do work for the Project. A person who does not want to do a task
> which has been delegated or assigned to them does not need to do
> it. However, they must not actively work against these rules and
> decisions properly made under them.
>
> If you're saying "I want to do this work, but it introduces a problem
> for those other people. Heck, I don't care, let them deal with it",
> you're "imposing an obligation to do work for the Project" on others.
Not at all. Nothing obligates anyone to do work on kFreeBSD, systemd,
or any other technology; people choose to do so.
To use an analogous example, consider two packages, libfoo1 and bar,
with bar depending on libfoo1. Nothing obligates the maintainer of
libfoo1 to update bar to work with libfoo2, nor does anything obligate
the maintainer of bar to update bar to work with libfoo2. When libfoo1
goes away because it has inherent bugs that nobody plans to fix (or
*can* fix without breaking ABI), nothing obligates the maintainers of
either libfoo2 or bar to fix the resulting RC bug on bar, either by
porting bar to libfoo2 or maintaining libfoo1 indefinitely. And when
that bug gets reassigned to ftp.debian.org, nothing obligates the
ftpmasters to remove bar. :)
> > As this thread has demonstrated, people can very sensibly argue that
> > both kFreeBSD and systemd have value; kFreeBSD does not automatially
> > win that argument by saying "frist psot".
>
> I'm not saying the kFreeBSD people shouldn't have to do anything at all
> to support systemd. However, given the above, I think it's only fair if
> systemd advocates who wish to see systemd become the default in Debian
> will do the hard work to make that happen, and not try to chicken their
> way out because "kFreeBSD is a toy architecture".
You've entirely ignored my point, and then reasserted that you believe
kFreeBSD wins the argument by default, by implying that if someone
doesn't do the work then systemd loses.
I certainly agree that the best-case scenario involves a peaceful
coexistence of systemd and kFreeBSD. I described a likely scenario for
such peaceful coexistence at the top of this mail. However, in the
event that no such coexistence can happen, neither systemd nor kFreeBSD
inherently gets to say "well, we win, go away and don't come back".
- Josh Triplett
Reply to: