From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2929 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: "Serge E. Hallyn" Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: Readiness notification exemplars Date: Wed, 1 Apr 2020 11:26:00 -0500 Message-ID: <20200401162600.GA31582@mail.hallyn.com> References: <20200401142122.GA30742@mail.hallyn.com> <20200401152832.GA31205@mail.hallyn.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="118902"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/1.9.4 (2018-02-28) Cc: Supervision To: Laurent Bercot Original-X-From: supervision-return-2518-gcsg-supervision=m.gmane-mx.org@list.skarnet.org Wed Apr 01 18:26:02 2020 Return-path: Envelope-to: gcsg-supervision@m.gmane-mx.org Original-Received: from alyss.skarnet.org ([95.142.172.232]) by ciao.gmane.io with smtp (Exim 4.92) (envelope-from ) id 1jJgBl-000Uow-U3 for gcsg-supervision@m.gmane-mx.org; Wed, 01 Apr 2020 18:26:01 +0200 Original-Received: (qmail 17430 invoked by uid 89); 1 Apr 2020 16:26:28 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm Original-Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Original-Received: (qmail 17419 invoked from network); 1 Apr 2020 16:26:27 -0000 Content-Disposition: inline In-Reply-To: Xref: news.gmane.io gmane.comp.sysutils.supervision.general:2929 Archived-At: On Wed, Apr 01, 2020 at 03:59:25PM +0000, Laurent Bercot wrote: > > You'd have to buy into it with a syscall that says "let me know when > > something listens on tcp port N". In turn s6-supervise would only do > > that if some config said "don't start service Y until something (which > > is expected to be service X) proves it's ready by listening on port N". > > The idea was to handle cases like libvirt being ready to accept VM > > managing requests. > > Yes, so it's not only about adding a pollable fd to a fd set, it's > also telling the kernel what kind of notifications you're interested > in receiving. So that means: for the supervisor, designing and parsing > a config file; for the service writer, writing a supervisor-specific > config file. > > You added complexity to the supervisor, made it more difficult to > change supervisors by locking in service config files, added burden to > packagers, and turned a two-way transaction into a three-way one (that > now includes the kernel). All this to achieve one benefit: make no > changes to daemons. It seems very much not worth it. Yes. If making changes to daemons were going to palatable, then an explicit "I am ready" API would be best. That still would require the same changes to the service managers. But it would be unambiguous. > Also, "Don't start service Y until something is ready" is not the > supervisor's job, it's the service manager's. The supervisor only > reports service readiness; the service manager can make use of it if > needed. If your mechanism assumes that the supervisor and the service > manager are one and the same program, it enforces a monolithic design - > systemd people will love it, but I won't. Don't think that should matter here. When those are separate then the service manager can do it all. > > Not all of it. But it appears to me the whole world gave into systemd > > for the sake of socket activation > > Yeah, based on propaganda and hype. Doesn't mean it's good tech, and > I don't understand the urge to add to the problem. There are pros and cons, but you are arguing for parsing stdout for a text message and/or using pidfiles (written to an fd). The former is bad because stdout text changes as code evolves. The latter is bad as you've mentioned because pidfile ready != service ready. > > and in my time handling upstart > > service dependency for ubuntu server, availability over the network was > > the most common, perhaps even the only, usable metric. > > It's just a question of setting up IPCs. It's only important to know > when a service is ready because you want to communicate with that > service, so in theory you could exhaustively list all existing IPC > mechanisms (of which inet domain sockets would be the most common), > and make it work that way. I still don't think it would be a good idea. It might not be. I'm still looking for good reasons why it wouldn't be. > > Mind you I'm certainly open to the idea that maybe this isn't worth > > doing - else I'd have actually implemented it by now :) But so far I've > > not seen anything that seems as good, let alone better. > > I'm looking at the total amount and distribution of effort. > Adding s6-style readiness notification to an existing daemon is like > 4 lines of code, and the effort is trivially distributed, so it's easy. > (And running such a daemon under another supervisor is also easy, see > sdnotify-wrapper.) > Your proposal requires > - adding stuff to the kernel: significant effort for kernel devs > - forcing supervisors to add config options to support it: significant > effort for supervisor devs, and breaks cross-OS portability > - forcing distros to add config options to enable it: small amount of > effort, easily distributed > - the only people it doesn't impact is daemon code maintainers > - the kernel is now involved in something that could be handled in a > pure userland way with existing mechanisms > > So, how much has the daemon code maintainers lobby paid you, and how > can I get a share of it? :P Yeesss, those sweet, deep, daemon code maintainer lobby pockets