From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/535 Path: main.gmane.org!not-for-mail From: Gerrit Pape Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: svlogd -tt Date: Tue, 27 Jul 2004 11:28:05 +0000 Message-ID: <20040727112809.10300.qmail@84ce64a3ba6fa7.315fe32.mid.smarden.org> References: <40FD6BB6.5000902@zweipol.net> <20040723102024.28233.qmail@67ec0c2e018e31.315fe32.mid.smarden.org> <41054FEB.2090305@zweipol.net> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1090927684 30528 80.91.224.253 (27 Jul 2004 11:28:04 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Tue, 27 Jul 2004 11:28:04 +0000 (UTC) Original-X-From: supervision-return-773-gcsg-supervision=m.gmane.org@list.skarnet.org Tue Jul 27 13:27:50 2004 Return-path: Original-Received: from antah.skarnet.org ([212.85.147.14]) by deer.gmane.org with smtp (Exim 3.35 #1 (Debian)) id 1BpQ7a-0001vm-00 for ; Tue, 27 Jul 2004 13:27:50 +0200 Original-Received: (qmail 9520 invoked by uid 76); 27 Jul 2004 11:28:11 -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 9515 invoked from network); 27 Jul 2004 11:28:11 -0000 Original-To: supervision@list.skarnet.org Mail-Followup-To: supervision@list.skarnet.org Content-Disposition: inline In-Reply-To: <41054FEB.2090305@zweipol.net> Xref: main.gmane.org gmane.comp.sysutils.supervision.general:535 X-Report-Spam: http://spam.gmane.org/gmane.comp.sysutils.supervision.general:535 On Mon, Jul 26, 2004 at 08:39:39PM +0200, Henrik Heil wrote: > >When making it a runtime option, there must be a decision whether svlogd > >shall maintain two different sets of files in the log directory, or > >filename conversion should be done. > > Thinking about these alternatives i must admit that both seem to have a > drawback -- and that i underestimated the complexity of switching the > formats. > > Different sets (if i understood that right) means that it is not > intuitive what the maximum number of old log files from the config > means. It cannot mean num=TAI+UTC because in this case svlogd could not Yes. But even so this looks like the best way to do it if at all. svlogd would maintain two different sets of log files (one set with TAI-filenames, one with UTC-filenames) independently, according to its configuration. When changing the configuration, and "current" gets big enough, svlogd adds it to the currently configured set, leaving the other set of log files alone. If desired, the log files could be converted from one file name to the other manually using a separate tool (this again raises the request for a tai64nlocal alike program), or removed. But I'm not convinced that it's worth the trouble to implement this or similar. There still is the idea of a log processor program (svlogp) which could be also used to list the log files in a directory with human readable names, or gives convenient access to the logs by other means. > What do you think about a runtime option for UTC-filenames that only > comes into effect if there are no TAI-filenames in the log directory and > vice versa? I'm not sure; svlogd at least should print a warning in this case, which then ends up in the readproctitle log. It's not that intuitive to users, and susceptible to misunderstandings in my opinion. Regards, Gerrit.