From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2629 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: "Casper Ti. Vector" Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: [Announce] s6.rc: a distribution-friendly init/rc framework Date: Mon, 3 Jun 2019 17:30:41 +0800 Message-ID: <20190603093041.GA10891@CasperVector> References: <20180322132334.GA11596@caspervector> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="240923"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.12.0 (2019-05-25) To: supervision@list.skarnet.org Original-X-From: supervision-return-2219-gcsg-supervision=m.gmane.org@list.skarnet.org Mon Jun 03 11:30:50 2019 Return-path: Envelope-to: gcsg-supervision@m.gmane.org Original-Received: from alyss.skarnet.org ([95.142.172.232]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1hXjIm-0010Wl-M5 for gcsg-supervision@m.gmane.org; Mon, 03 Jun 2019 11:30:48 +0200 Original-Received: (qmail 19567 invoked by uid 89); 3 Jun 2019 09:31:13 -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 19560 invoked from network); 3 Jun 2019 09:31:12 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:date:to:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=zRgjtHANRLDCCrLqzCjKn43L+Y/OBqwKk5h80NQchZA=; b=je3VZaeKq0EEsv/3kLy2B5B1gZdOMw+8HZk+h6WY+pHXpfJqsUsQ6FZ+jLkofUeCvW M9GDpJ3yY5AtkHLKOSZPN49KC5a1NQ9vaCsrFJwQS4LPFEjTYbV80GFSX7Xr33KNKH0Z xGUNRN/C99xACbxqn1F5WaJBRedFSDIHzWmC/tzG3GVkLMgvp30BhCrRUiXZQD2CFiyX vxczvpayExgWSYDobszfaWYUlYa3CpnKwC9ijqOVDWvkn9SpBpX4ZBWlu9zP5vkaLx/f ItYvParOqcX4UP2EAPlrWs/bU+djve3kE+krmWa4d4uiUZo39JYIqWCN7qU0A/D2eUuS j5Jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:subject:message-id:mail-followup-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=zRgjtHANRLDCCrLqzCjKn43L+Y/OBqwKk5h80NQchZA=; b=N+Jrld4BuDmqRIkP70ehRogkKza8uHCQtqihBvTHAO+8DCRpgw/f7kF+QBx3VeXHci Xz3ws3xcG203G04LDffmDpZ9LFcv09s+gqaLYWjXPmRdc9e3ZRYDApnkhoMUJWDyZIIf vWCnmbdn54q9xuwr62AbwFk3jbLmoV56M9YIWnIbLzQPFuCtmvwZFcDpy/AlxAZ6xQC5 Ydbryeg2epTrfhjlPFdlj9jrDlg2IfLDIs7jAKyn1RMCgCat5HvHj9cb2AqrjWUyhoqg HoDgOQCjTscMLbdC1JOmPoZBhDzsSqjfsfI9WawofrbcWXEWxfeDBxlW8tXxFHYsXqDv xDWw== X-Gm-Message-State: APjAAAXEJW6j2FWAy8qeYultksOhjLsrG1TnMzfcInjq8sx1jSB1yf5Z 9paUvz+DHeuP9P3lmQYKZIQ8xf7l X-Google-Smtp-Source: APXvYqykCzt4uy0vic/dJQJ4zwUEeD+HoGSnFX0lNfxo/VrVTC79haKIUiPITsxqO6xAJTqKawpOyg== X-Received: by 2002:a17:902:9b85:: with SMTP id y5mr28072961plp.313.1559554244717; Mon, 03 Jun 2019 02:30:44 -0700 (PDT) X-Google-Original-From: "Casper Ti. Vector" Mail-Followup-To: supervision@list.skarnet.org Content-Disposition: inline In-Reply-To: Xref: news.gmane.org gmane.comp.sysutils.supervision.general:2629 Archived-At: On Thu, Mar 22, 2018 at 05:10:58PM +0000, Laurent Bercot wrote: > Having one stream per syslog client is a good thing per se because > it obsoletes the need to identify the client in every log record; > but the killer advantage would be to do away with system-wide > regular expressions for log filtering, and that's not something > we have yet. Even when you pipe "s6-ipcserver ucspilogd" into > s6-log, your s6-log script is the same for every client, so the > regexes need to be global. A real improvement would be to have > a different log script for every client connection, so the log > filtering would really be local; but I haven't yet thought about a way > to design such an architecture. That's the main reason why I haven't > much pushed for SOCK_STREAM syslog() in musl; if we can come up with a > syslogd scheme that works without any global regexes, then we'll > have a real case for SOCK_STREAM adoption. Until then, socklog works. Assuming the number of syslog logging scripts is fairly small (a few for daemons in an anticipated list, and perhaps one for the rest; I think this scheme is actually already in use by most syslog users), what about setting up a group of s6-log consumer services, and use a chainloading program (akin to s6-tcpserver-access) with s6-ipcserver to dynamically decide which consumer to connect to (by interacting with s6rc-fdholder)? (I think this scheme, with some variations, can also be usable with services that produce multiple output streams, like Apache which is recently discussed on this mailing list. This would be particularly easy if these services can be configured to log to /proc/self/fd/[num]: then the user can simply use s6-fdholder-retrieve to chainload the daemons for the services.) -- My current OpenPGP key: RSA4096/0x227E8CAAB7AA186C (expires: 2020.10.19) 7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C