From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 0A421138359 for ; Tue, 17 Nov 2020 00:22:57 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C5630E0993; Tue, 17 Nov 2020 00:22:51 +0000 (UTC) Received: from mail-qt1-f169.google.com (mail-qt1-f169.google.com [209.85.160.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 3779CE0964 for ; Tue, 17 Nov 2020 00:22:51 +0000 (UTC) Received: by mail-qt1-f169.google.com with SMTP id m65so14455065qte.11 for ; Mon, 16 Nov 2020 16:22:50 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:reply-to:subject:to:cc:mime-version :references:in-reply-to:message-id:content-disposition :content-transfer-encoding; bh=C7REcYKrXtjikDuVeVtstZ4jN/2uz2qVHsOpye4Mb9A=; b=TXcwkYYf/bUAqktdWJ/Gs9Bp3vF0cGdJ3B7nO35bzE2zq7Pc+8yOHcyYEDb08LBS0G l9yvgssg82TXqkXhhf/9uWEW/zOYsT9WnyfBULy7gGq/YasFJrKZrJDwO7tD2ISoyLjf 6I5h+Yf6OwPIOgVnOtGEfOJ/qDujwAon+yXOcfui9OKF1Koyih0YJ6heNhfzPicq9BPo 4Nj0BBDYTlzN4jjR+Exmh1stVkEcIPTiLuanxYXkct3cKTVii2rJ9kIFXcoPdFUHMwsX ZQr7XyjCIpzLGVZ+VdnJCm+ec2UTB0QGjfNJlYGGY0QJ+pyqfOFxt0cuu4lnzxnxtIqs V8Aw== X-Gm-Message-State: AOAM530fZnT6zhWBL5RDyuJ3jrMRpUJZ+kSmy9yoT613TMpCfe3YSBDc k4+ZY+yvo+N0bOTAAUkctAnSRHAoRnmtyw== X-Google-Smtp-Source: ABdhPJzQW8So3CsGieOGh0GSyFOROiLo1cN41bapSLLi/8hjibOOUMojE1vxaLIPY60H8YCtvKU4Nw== X-Received: by 2002:aed:3ae5:: with SMTP id o92mr16886532qte.265.1605572570235; Mon, 16 Nov 2020 16:22:50 -0800 (PST) Received: from ffortso9 (c-76-23-130-96.hsd1.ct.comcast.net. [76.23.130.96]) by smtp.gmail.com with ESMTPSA id n93sm13041767qtd.7.2020.11.16.16.22.49 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Nov 2020 16:22:49 -0800 (PST) Date: Mon, 16 Nov 2020 19:22:48 -0500 From: Jack Subject: Re: [gentoo-user] odd issue with RTKIT syslog-ng To: gentoo-user@lists.gentoo.org Cc: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 References: In-Reply-To: X-Mailer: Balsa 2.6.1-108-g709771d0f Message-Id: <4JZI3GTM.5DK32STY.2GJR5DT7@4CJOC7Q6.CDYBV4NG.QGHV3UOT> Content-Type: text/plain; charset=us-ascii; DelSp=Yes; Format=Flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 315eac8d-3511-4c6a-8e47-745c82f707a6 X-Archives-Hash: 9ac019b0da9330fd221a002be2d25e7c On 2020.11.15 19:02, Jack wrote: > As usual, I've got what seems to be a really obscure problem, and I =20 > have not found any reference to it searching the interwebs. >=20 > The suspect package is sys-auth/rtkit-0/13-r1 (which has nothing to =20 > do with chkrootkit) and I'm using app-admin/syslog-ng-3.26.1-r1. >=20 > As a typical example from /var/log/messages (extract, and having =20 > reconfigured syslog-ng to us iso timestamps) >=20 > 2020-11-15T18:30:01-05:00 localhost CROND[7320]: (root) CMD =20 > (/usr/lib/sa/sa1 1 1) > 2020-11-15T23:34:10-05:00 localhost rtkit-daemon[6263]: Supervising 0 =20 > threads of 0 processes of 0 users. > 2020-11-15T23:36:38-05:00 localhost rtkit-daemon[6263]: Supervising 0 =20 > threads of 0 processes of 0 users. > 2020-11-15T18:40:01-05:00 localhost CROND[15943]: (root) CMD (test -x =20 > /usr/sbin/run-crons && /usr/sbin/run-crons) >=20 > All rtkit messages to syslog seem to be in UTC, or at least five =20 > hours off from my local Americas/New York timezone. rtkit uses the =20 > syslog() call for all logging, and there is nothing in those calls =20 > that even mentions timezone. >=20 > However, in digging further, I found two log entries from rtkit which =20 > do appear to be using local time. In looking at the rtkit source, =20 > those two use the LOG_INFO and LOG_NOTICE as their levels. All other =20 > logging in rtkit uses LOG_ERR, LOG_DEBUG, or LOG_WARNING, with one =20 > exception: I see one LOG_INFO message (repeated, scattered across =20 > the log) which does show the UTC time. >=20 > So, does anyone have an idea what is going on? >=20 > I have one theory so far, but I a bit stuck on how to test it. I'm =20 > not sure where in the boot process rtkit gets started, but I think =20 > it's automatically started when Dbus starts. As part of the daemon's =20 > startup routine, it drops some privileges. Is it possible that the =20 > applicable timezone gets changed when it drops privileges? As far as =20 > I can tell, the log messages with the correct time are all produced =20 > before it drops privs. Am I barking up the right tree, or am I =20 > barking mad? I've done some more digging, with lots of debugging output. Up to a =20 point, the process acknowledges the local timezone. However, after =20 doing a 'chroot "/proc"' and then 'chdir "/"' it thinks it's UTC. =20 Still doesn't make any sense to me, though.