From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.FoxValley.net (mail.FoxValley.net [64.135.192.34]) by sourceware.org (Postfix) with SMTP id 2B3843858D1E for ; Sat, 19 Feb 2022 20:35:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2B3843858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=foxvalley.net Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=foxvalley.net Received: (qmail 29694 invoked from network) for libc-alpha@sourceware.org; 19 Feb 2022 14:34:35 -0600 Received: from 161-97-241-227.lpcnextlight.net (HELO ?192.168.1.3?) (draymond@161.97.241.227) by mail.foxvalley.net with SMTP; 19 Feb 2022 14:34:35 -0600 Message-ID: <1b23aaf9-1420-ba1d-c94b-ce2934c669cc@foxvalley.net> Date: Sat, 19 Feb 2022 13:35:33 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Subject: Re: [PATCH v2 7/7] misc: syslog: Use RFC5424 Content-Language: en-US To: libc-alpha@sourceware.org References: <20220218142322.432304-1-adhemerval.zanella@linaro.org> <20220218142322.432304-8-adhemerval.zanella@linaro.org> From: Dan Raymond In-Reply-To: <20220218142322.432304-8-adhemerval.zanella@linaro.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_NUMSUBJECT, NICE_REPLY_A, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Feb 2022 20:35:36 -0000 On 3/9/2021 4:45 PM, Dan Raymond via Libc-alpha wrote: > I noticed an issue with syslog() timestamps. When a client generates a > timestamp inside a call to syslog() it uses localtime_r(). When the > server (syslogd) generates a timestamp it uses localtime(). The > observable difference is that localtime() checks the timezone settings > while localtime_r() does not. Hence if you change the timezone settings > while syslogd is running: server-generated timestamps will be correct > while client-generated timestamps will be incorrect. > > Is this something that should be fixed? There are various ways to > mitigate the problem but none are ideal: > > 1) reboot or restart all processes using syslog() after changing the > timezone (this may not be possible/practical) > > 2) call tzset() from all processes using syslog() after changing the > timezone (not likely to be possible) > > 3) start syslogd with -t command line option to disable client-generated > timestamps (timestamp accuracy is decreased) > > On the other hand, switching from localtime_r() to localtime() inside > syslog() could adversely impact performance. For instance it could > incur an additional call to stat('/etc/localtime', ...) for each call to > syslog(). This cost would be avoided if the calling process sets the TZ > environment variable, however, since only changes to TZ would > subsequently trigger a filesystem access. Thoughts? > Adhemerval, since you have been making changes in this area recently I wonder if you had any comments about the issue I raised last year (quoted above)?