From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.comp.sysutils.supervision.general/2411 Path: news.gmane.org!.POSTED!not-for-mail From: Guillermo Newsgroups: gmane.comp.sysutils.supervision.general Subject: Re: Log rotation issue with runit Date: Tue, 25 Dec 2018 15:17:17 -0300 Message-ID: References: NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1545761725 18301 195.159.176.226 (25 Dec 2018 18:15:25 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 25 Dec 2018 18:15:25 +0000 (UTC) Cc: 916230-quiet@bugs.debian.org To: Supervision Original-X-From: supervision-return-2001-gcsg-supervision=m.gmane.org@list.skarnet.org Tue Dec 25 19:15:21 2018 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.84_2) (envelope-from ) id 1gbrEd-0004dE-UE for gcsg-supervision@m.gmane.org; Tue, 25 Dec 2018 19:15:20 +0100 Original-Received: (qmail 9141 invoked by uid 89); 25 Dec 2018 18:17:56 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm Original-Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 9134 invoked from network); 25 Dec 2018 18:17:56 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=GwwAS7+baJsQZ5XUrojcLOmIDs67pivn++tb9S1HNh8=; b=PPFbrAv4dUcVK3B2IOB4QoKYkbJX6BaBzgS6Ib71LKxWS/opnQuigzxkZHom9YvAj6 9uDWN3fuSEC/xMo6sXR6oWUVARHcJVpqqM2eg8KFHzrdeesf0Rp3WcPou4fwkbYrJ2o6 xSPpSXqibQNGRDo0bDfTOYbUjwXQ5xvMOZebZxk6ydUHBz7bdGJPeI1/hacwvCsXy32v I8dVMNNQ31M0L/7nLaZLztM+VXo6YLD2mjtYvzlOiqBL7q1KjWYWJ/XshHPmWcJPexZz VkCvkVub2yp5ZJ+dnarhx7kmPlvtvwIlvuJhR81g42XCa5qm8HroDAQs2p8eEI6Qnkdn Oa1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=GwwAS7+baJsQZ5XUrojcLOmIDs67pivn++tb9S1HNh8=; b=g+rY5WluH9y1aqOrtOYDM3zZf6zSlzfH3Ce9PLK4893LkEbMvtAG1/3lp9X0PBogea tUXGNDUmZ2C8uylZth0s17K7hLO+gqtle1UhZkPgyVRSfqFbROt2mJRbf2rVl7NlVZxG 8JGH6zADWHEtEiBP3ptUissDOd+8wNtitiHXt+URSIrNCh5j8eLJIZQgJA88eVnnzr9o NJHX/U5iua+AziS1nXl270l4+FKxw1+hysaTWqO6N/gsltLsKEUpnA4mQk1fwR3HM45U Da3F8zlpiLurGVN1YzFfT6f1vRjPHLP3CBpQzPY1I5HDiRog5ra6Exne35y/+WiAEyWJ u9sg== X-Gm-Message-State: AA+aEWY09eLHqnekAx0HPo7qw7y0f5z+LrupKbV123g+WOSlNe1eU1al wqRO2bwywAwW2+nVgIpwR80j9lAGfiPL88OmxEBlYA== X-Google-Smtp-Source: ALg8bN6vXcEPP24LurYNqViALdI8IUPBKfEugyBRHZj5kkYA8bwFEXvEIkO45L6OVIw//RWx/MqOfP8cv7uY+K4423o= X-Received: by 2002:a24:878c:: with SMTP id f134mr11201398ite.81.1545761848392; Tue, 25 Dec 2018 10:17:28 -0800 (PST) In-Reply-To: Xref: news.gmane.org gmane.comp.sysutils.supervision.general:2411 Archived-At: El mar., 25 dic. 2018 a las 10:39, Dmitry Bogatov escribi=C3=B3: > > Hello! > > I am Debian maintainer of `runit' supervision suite. Recently, I > received bug report [^1] about stray .u logfiles. After some > investigation I found code, that caused issue, but it seems that it was > written with some purpose, yet I fail to understand that purpose. > > Author Gerrit Pape directed me here. Any clarification would be welcome! > Please keep bug in thread. > > [^1] https://bugs.debian.org/916230 It was likely written on purpose. A 'current' file that doesn't have the execute by owner permission set is not considered to completely processed, and becomes a .u file instead of being appended to. As has been said, it can happen if svlogd does not exit cleanly. Although it doesn't seem to be mentioned in svlogd's man page, this comes from daemontools' multilog program, which inspired svlogd: * https://cr.yp.to/daemontools/multilog.html (section "Automatically rotated logs") On the other hand, it seems to me that the patch used for resolution of bug #878476 prevents all .u files from being deleted, so they would indeed accumulate indefinitely. Both .u and .s files are supposed to be deleted when they are the oldest file in the logging directory, to honor 'u' lines in 'config' files, and this is only a problem when the one about to be fed to a processor happens to be the one chosen for deletion because of a wonky clock. This issue was brought up earlier in this mailing list, and a different patch was suggested: * https://www.mail-archive.com/supervision@list.skarnet.org/msg00667.html This one seems to do the right check, maybe it should have been applied ins= tead? G.