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 9051 invoked from network); 4 Nov 2020 17:35:58 -0000 Received: from alyss.skarnet.org (95.142.172.232) by inbox.vuxu.org with ESMTPUTF8; 4 Nov 2020 17:35:58 -0000 Received: (qmail 26901 invoked by uid 89); 4 Nov 2020 17:36:20 -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 26894 invoked from network); 4 Nov 2020 17:36:20 -0000 From: "Laurent Bercot" To: "billa chaitanya" , supervision@list.skarnet.org Subject: Re: S6-log Date: Wed, 04 Nov 2020 17:35:54 +0000 Message-Id: In-Reply-To: References: Reply-To: "Laurent Bercot" User-Agent: eM_Client/8.0.3385.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: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedujedruddthedguddtfecutefuodetggdotffvucfrrhhofhhilhgvmecupfgfoffgtffkveetuefngfdpqfgfvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvufffkfgjfhhrfgggtgfgsehtqhertddtreejnecuhfhrohhmpedfnfgruhhrvghnthcuuegvrhgtohhtfdcuoehskhgrqdhsuhhpvghrvhhishhiohhnsehskhgrrhhnvghtrdhorhhgqeenucggtffrrghtthgvrhhnpedvgfevffeuleegvdektdffteegvdeiieefkeetgfeuheffheelheejhfevueeijeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphhouhht >1) does the log service of a corresponding long run service goes down when >the long run service is made down using some s6 commands? (like s6-rc -d >change No, because as Crest says, a producer foo depends on a consumer=20 foo-log, not the other way around, so bringing up foo also forces foo-log to be up, but bringing it down does not force foo-log to be down. (Bringing down foo-log, however, forces foo to be down.) s6-rc provides you with a natural solution to this, though: in your foo-log definition directory, you can define a "pipeline-name" file: that will automatically create a bundle containing foo and foo-log, named after the contents of pipeline-name. If you do, for instance: echo foo-pipeline > foo-log/pipeline-name and recompile your database, then s6-rc -u change foo-pipeline will always bring up foo *and* foo-log, and s6-rc -d change foo-pipeline will always bring down foo *and* foo-log. >2) Shall we use s6-log for one shot services too? s6-log is a long-lived process, designed to log the output from long-lived process. It doesn't really make sense to use a dedicated logger for a oneshot. What s6-rc does is that the output from all your oneshots is sent to the catch-all logger, i.e. the place where the supervision tree sends its output by default. If you are using a s6-linux-init installation, or similar, chances are that this catch-all log is itself handled by a s6-log process. Check your /run/uncaught-logs directory. >3) is there any command-line option we can provide to s6-log for stopping >the running s6-log? To stop a running s6-log process, simply send it a SIGTERM. If the s6-log process you want to stop is supervised, the command you want is probably s6-svc -d /run/service/foo-log Be aware, though, that if you stop a logger without stopping the corresponding service, funny things can happen when the logging pipe fills up: depending on how the service is written, it may lose logs, or it may hang, or it may die. You should probably never have to stop a logging process without bringing down the entire pipeline that leads to it. -- Laurent