From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 15768 invoked from network); 13 Jun 2020 12:43:03 -0000 Received: from alyss.skarnet.org (95.142.172.232) by inbox.vuxu.org with ESMTPUTF8; 13 Jun 2020 12:43:03 -0000 Received: (qmail 28949 invoked by uid 89); 13 Jun 2020 12:43:28 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Received: (qmail 28942 invoked from network); 13 Jun 2020 12:43:28 -0000 From: "Laurent Bercot" To: =?utf-8?q?Carl=20Winb=c3=a4ck?= Subject: Re: Logging in a web server context Cc: supervision@list.skarnet.org Date: Sat, 13 Jun 2020 12:42:59 +0000 Message-Id: In-Reply-To: <20200613105942.GA21613@klumpi.ignorelist.com> References: <20200613105942.GA21613@klumpi.ignorelist.com> Reply-To: "Laurent Bercot" User-Agent: eM_Client/7.2.37929.0 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrudeifedgheegucetufdoteggodftvfcurfhrohhfihhlvgemucfpfgfogfftkfevteeunffgpdfqfgfvnecuuegrihhlohhuthemuceftddtnecunecujfgurhephffvufffkfgjfhhrfgggtgfgsehtqhertddtreejnecuhfhrohhmpedfnfgruhhrvghnthcuuegvrhgtohhtfdcuoehskhgrqdhsuhhpvghrvhhishhiohhnsehskhgrrhhnvghtrdhorhhgqeenucggtffrrghtthgvrhhnpedvgfevffeuleegvdektdffteegvdeiieefkeetgfeuheffheelheejhfevueeijeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphhouhht >I'm not completely sure about s6, but runsv (from runit) hands only the >stdout of the ./run script to the logger, and passes the stderr out of >it's own stderr. All daemontools-inspired supervision suites, including s6, follow that model, so yes, your runit example can be directly applied to s6. Generally speaking, supervision suites only provide integrated support (i.e. a pipe that is already created and maintained by the supervision tree) for one output channel, and if a service needs other output channels then it's of course possible but the plumbing must be done manually. In Carl's case: in order to have foo's stdout logged by a dedicated logger, and foo's stderr by *another* dedicated logger, then you can do something like the following: - If /service/foo is your service directory for foo, then you declare your service directory for foo's stdout in /service/foo/log. - mkfifo -m 0600 /service/foo/stderr-pipe - In /service/foo/run, redirect stderr to stderr-pipe - Write a separate service directory, say /service/foo-stderr-log, with a run script that redirects its stdin from /service/foo/stderr-pipe and execs into s6-log. This should do what you want, with a small caveat: if the process for foo-stderr-log dies, then you'll need to restart foo in order to get any further logs, because the pipe has been broken and isn't maintained by the supervision tree like the pipe to foo/log is. The way to prevent this is to use a fd-holder, and s6 provides tools for that, but it's the next level of complexity. Historically, the vast majority of daemons have only needed one output channel, and that is why supervision suites address the common case but offer no help otherwise; unfortunately, certain web servers buck the trend and need several output channels (which is not a bad idea per se, it's just that the tooling to handle it in a user-friendly way is not there yet), so for now the way to address it is still to whip out the hammer and screwdriver. s6-rc wouldn't help you in that case, because its funnel model still only supports one consumer per producer, and extra output channels have to be set up manually as well. The nginx/apache case is something that comes up with some regularity, either on this list or on the #s6 channel, so I should try and write some tools that make it easier to automate. However, it is likely that those tools would become part of s6-rc, not s6, because doing things in a reliable way involves a fdholder, which requires some policy that s6 does not provide but s6-rc does (and s6-rc already has all the necessary infrastructure). -- Laurent