From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/1430 Path: news.gmane.org!not-for-mail From: Adam Megacz Newsgroups: gmane.comp.sysutils.supervision.general Subject: svlogd in funny states; reason for not integrating into runsv? Date: Tue, 05 Jun 2007 17:21:23 -0700 Organization: Myself Message-ID: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1181089516 22046 80.91.229.12 (6 Jun 2007 00:25:16 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 6 Jun 2007 00:25:16 +0000 (UTC) To: supervision@list.skarnet.org Original-X-From: supervision-return-1667-gcsg-supervision=m.gmane.org@list.skarnet.org Wed Jun 06 02:25:14 2007 Return-path: Envelope-to: gcsg-supervision@gmane.org Original-Received: from antah.skarnet.org ([212.85.147.14]) by lo.gmane.org with smtp (Exim 4.50) id 1HvjKq-0004On-Pp for gcsg-supervision@gmane.org; Wed, 06 Jun 2007 02:25:12 +0200 Original-Received: (qmail 1311 invoked by uid 76); 6 Jun 2007 00:25:34 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Archive: Original-Received: (qmail 1305 invoked from network); 6 Jun 2007 00:25:34 -0000 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 22 Original-X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: chaitin.megacz.com X-Home-Page: http://www.megacz.com/ User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) Cancel-Lock: sha1:ERYgzuFK32IeRjmsD6dGrSWbJxA= Original-Sender: news Xref: news.gmane.org gmane.comp.sysutils.supervision.general:1430 Archived-At: I've found runsv to be exceptionally reliable in terms of noticing changes in /var/service/ and adapting its behavior accordingly. Really solid. Unfortunately, I have not found svlogd to be as robust. It often gets into funny states or fails to pick up changes -- or just never starts altogether. This might actually be runsv's fault rather than svlogd's fault; I guess I'm just saying that the management of the "logging process" is not as amazingly solid as the management of the "service process". Is there a reason why the svlogd functionality is not integrated into runsv? It seems that as the parent of the service process, runsv is in the ideal position to gather and log the process' output. This would also keep the process table/tree a lot cleaner; only one runit-related process per service rather than two. - a -- PGP/GPG: 5C9F F366 C9CF 2145 E770 B1B8 EFB1 462D A146 C380