upstart socket activation
Scott James Remnant
scott at netsplit.com
Mon Mar 28 16:49:50 UTC 2011
On Mon, Mar 28, 2011 at 9:05 AM, Lennart Poettering
<mzhcfgneg at 0pointer.de> wrote:
> On Mon, 21.03.11 11:38, Clint Byrum (clint at ubuntu.com) wrote:
> > > If the fds are only passed along the socket
> > > activation event object, then the fds might come too late. So no, this
> > > is not at all a superset of what systemd does, but just a classic inetd
> > > reimplementation...
> > >
> > Indeed, there needs to be a standard way for daemons to communicate with
> > the system to make sure connections are always being acknowledged and
> > passed to the daemon. If systemd has already been successful in patching
> > daemons, upstart should probably emulate that same API.
> Yes, it should.
> In fact we tried to get Scott into a discussion about a common API
> definition for this and other similar smaller interfaces for usage in
> daemons. Alas, Scott's only reply was that our approach was "too
> simple", and nothing more specific.
No, you have never tried to get me into a discussion about anything.
Every now and then you pop up and tell me that I should do things your
way, then when I try and engage with you, you disappear and after a
while, the cycle starts all over again.
If you honestly want to have a discussion about creating a standard to
pass file descriptors from a process to its child, then I'm absolutely
all for that. If you want to bitch, I'm not.
> > I see this as a situation where we can share technology and establish a
> > standard that works well with both our solutions. The worst thing we can
> > do right now is disagree on how to ask daemon upstreams to patch their
> > daemons. If upstart does this one way that is entirely incompatible w/
> > systemd, and they both get real traction, then we will just create a
> > giant inefficiency and gridlock where we have daemons who have gone "the
> > upstart way" and others who have gone "the systemd way", and neither
> > trusting that the other is worth doing.
> Yupp. We tried this, and got basically told to bugger off, and so we
> did. Scott said pretty explicitly that he had no interest in cooperation
> on interfaces like this one, and that's that.
Again, no I haven't. If you're going to lie, you genuinely can "bugger off".
What I have said, again and again, is that I am absolutely interested
in working on interfaces together but that I'm not interested in
simply adopting yours where they don't match.
You can twist my words, but fortunately you can't twist mailing list
archives. Let's look at the discussion last time I tried to work with
you to create an interface together:
And I have at no point said I'm not interested in defining common
specs, all I've said is that I'm not interested in using your
interfaces as the common spec. I'm more than happy to sit down and
work something else that's fresh.
Seems I said pretty much the exact same thing last year. And what
happened? I spent a fair amount of time attempting to get you to
discuss an interface (others: see the dbus list for December +
January, there are several RFC passes of the patches), you went
silent, then finally you followed up with:
NAK. I plan to add a very different interface for bus
activation in systemd
now, so please do not merge this before this new scheme isn't clear.
So after accusing me (again) of not being willing to discuss things
with you, I once again tried to engage with you - you didn't bother -
and then you NAK'd my attempts at working together because *you* were
going to design (on your own) a very different interface for systemd
And again, I even responded on that bug to see whether you still
wanted to work together. And again, you have ignored it.
> If the opinions on cooperation on APIs on Canonical's side changed since
> then I am all ears. In fact I offered to come to UDS, if you guys want
> me to, and maybe we can discuss that there.
You aren't interested in cooperation, Lennart. You are only interested
in people doing things your way.
I am not going to do things your way, but I am still interested in us
finding new ways to do things together, if you would like.
More information about the upstart-devel