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 32816138359 for ; Mon, 16 Nov 2020 00:03:02 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8C59EE0932; Mon, 16 Nov 2020 00:02:56 +0000 (UTC) Received: from mail-qt1-f179.google.com (mail-qt1-f179.google.com [209.85.160.179]) (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 D334BE08FC for ; Mon, 16 Nov 2020 00:02:55 +0000 (UTC) Received: by mail-qt1-f179.google.com with SMTP id 7so11641180qtp.1 for ; Sun, 15 Nov 2020 16:02:55 -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 :message-id:content-disposition:content-transfer-encoding; bh=drCrtW+KydaB0caedk2X/UgtOb2aLe3TZS6efulAKfs=; b=Mzy8VMuA4txTSzwtvR2SYJVedPip88yEMF/PK21dZpqnZhTV0wXvjJPCNeaZzeEBCd /7BggBABryEBBqwsN57UPT9mwNhbZ2fXXDt+wxuRqPUFde9Cm7mje6Wxdec4LLopL5tB 8yu0htonpxWkq/Fz8AG5ZUYKJ6btDHns6qU+OZ87vcxJ+QAB2vmNlgm4iKKKvkrBMl+d nZfLkwtdB2rLNewmZZHMXz2I1mw7nvI09kxuEho9+ys3uJAi/eN3h7g6THkmNwBxGV3I LLYhLXnA9HGCLJC/LVOq66yw7EZAS29MuEnMX6M9eGYAs2IE+oCfwbgHGFR8P23r+UN1 ULuw== X-Gm-Message-State: AOAM533wUhWEOXjJEHX0R2kLrup2qkcgsCly9rpcSGDdlnpwjmBhCGbi Zei+Lgd3XLE/xnT1NYXu6pBY6xEyTjr9fQ== X-Google-Smtp-Source: ABdhPJxoZoGKTZlbXtm2GF9F58hDRRDe2cbgPKMSb4x9Z+7rxc4SrZxfs2og0h6JFRETOx4/tVfRmQ== X-Received: by 2002:ac8:6b4c:: with SMTP id x12mr12267121qts.359.1605484974858; Sun, 15 Nov 2020 16:02:54 -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 72sm11663191qkn.44.2020.11.15.16.02.54 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 15 Nov 2020 16:02:54 -0800 (PST) Date: Sun, 15 Nov 2020 19:02:53 -0500 From: Jack Subject: [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 X-Mailer: Balsa 2.6.1-108-g709771d0f Message-Id: Content-Type: text/plain; charset=us-ascii; DelSp=Yes; Format=Flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 10ea064f-6108-4c8a-bd04-a599ebf0c6a7 X-Archives-Hash: 617cf314cad5427a6ab558696e5ae880 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. The suspect package is sys-auth/rtkit-0/13-r1 (which has nothing to do =20 with chkrootkit) and I'm using app-admin/syslog-ng-3.26.1-r1. As a typical example from /var/log/messages (extract, and having =20 reconfigured syslog-ng to us iso timestamps) 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) All rtkit messages to syslog seem to be in UTC, or at least five hours =20 off from my local Americas/New York timezone. rtkit uses the syslog() =20 call for all logging, and there is nothing in those calls that even =20 mentions timezone. 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 the =20 log) which does show the UTC time. So, does anyone have an idea what is going on? I have one theory so far, but I a bit stuck on how to test it. I'm not =20 sure where in the boot process rtkit gets started, but I think it's =20 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 I =20 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 barking =20 mad? Thanks for any thoughts. Jack