Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #264851 > unrolled thread
| Started by | Albretch Mueller <lbrtchx@gmail.com> |
|---|---|
| First post | 2023-12-17 11:20 +0100 |
| Last post | 2023-12-17 15:10 +0100 |
| Articles | 20 on this page of 166 — 34 participants |
Back to article view | Back to linux.debian.user
difference in seconds between two formatted dates ... Albretch Mueller <lbrtchx@gmail.com> - 2023-12-17 11:20 +0100
Re: difference in seconds between two formatted dates ... Andy Smith <andy@strugglers.net> - 2023-12-17 12:00 +0100
Re: difference in seconds between two formatted dates ... <tomas@tuxteam.de> - 2023-12-17 12:10 +0100
Re: difference in seconds between two formatted dates ... Albretch Mueller <lbrtchx@gmail.com> - 2023-12-17 16:30 +0100
Re: difference in seconds between two formatted dates ... "Andrew M.A. Cater" <amacater@einval.com> - 2023-12-17 17:00 +0100
Re: difference in seconds between two formatted dates ... <tomas@tuxteam.de> - 2023-12-17 17:10 +0100
Re: difference in seconds between two formatted dates ... Andy Smith <andy@strugglers.net> - 2023-12-17 17:40 +0100
Re: difference in seconds between two formatted dates ... Albretch Mueller <lbrtchx@gmail.com> - 2023-12-17 23:50 +0100
Re: difference in seconds between two formatted dates ... Albretch Mueller <lbrtchx@gmail.com> - 2023-12-18 00:10 +0100
Re: difference in seconds between two formatted dates ... David Wright <deblis@lionunicorn.co.uk> - 2023-12-18 01:40 +0100
Re: difference in seconds between two formatted dates ... Albretch Mueller <lbrtchx@gmail.com> - 2023-12-18 02:20 +0100
Re: difference in seconds between two formatted dates ... David Wright <deblis@lionunicorn.co.uk> - 2023-12-18 07:00 +0100
Re: difference in seconds between two formatted dates ... Albretch Mueller <lbrtchx@gmail.com> - 2023-12-18 07:10 +0100
Re: difference in seconds between two formatted dates ... Greg Wooledge <greg@wooledge.org> - 2023-12-18 13:20 +0100
Re: difference in seconds between two formatted dates ... <tomas@tuxteam.de> - 2023-12-18 14:10 +0100
Re: difference in seconds between two formatted dates ... Greg Wooledge <greg@wooledge.org> - 2023-12-18 14:20 +0100
date can't parse its own output was: difference in seconds between two formatted dates ...) <tomas@tuxteam.de> - 2023-12-18 14:40 +0100
Re: difference in seconds between two formatted dates ... David Wright <deblis@lionunicorn.co.uk> - 2023-12-18 19:40 +0100
Re: difference in seconds between two formatted dates ... Greg Wooledge <greg@wooledge.org> - 2023-12-18 20:20 +0100
Re: difference in seconds between two formatted dates ... David Wright <deblis@lionunicorn.co.uk> - 2023-12-20 07:10 +0100
Re: difference in seconds between two formatted dates ... <tomas@tuxteam.de> - 2023-12-20 08:40 +0100
Re: difference in seconds between two formatted dates ... David Wright <deblis@lionunicorn.co.uk> - 2023-12-21 06:00 +0100
Re: difference in seconds between two formatted dates ... <tomas@tuxteam.de> - 2023-12-21 06:40 +0100
Re: difference in seconds between two formatted dates ... David Wright <deblis@lionunicorn.co.uk> - 2023-12-22 02:30 +0100
Re: difference in seconds between two formatted dates ... Greg Wooledge <greg@wooledge.org> - 2023-12-21 13:20 +0100
RTC and (old) Windows [was: difference in seconds between two formatted dates ...] <tomas@tuxteam.de> - 2023-12-21 13:30 +0100
Re: RTC and (old) Windows [was: difference in seconds between two formatted dates ...] David Christensen <dpchrist@holgerdanske.com> - 2023-12-21 23:30 +0100
Re: difference in seconds between two formatted dates ... David Wright <deblis@lionunicorn.co.uk> - 2023-12-22 02:40 +0100
Re: difference in seconds between two formatted dates ... Greg Wooledge <greg@wooledge.org> - 2023-12-22 04:10 +0100
Re: difference in seconds between two formatted dates ... Albretch Mueller <lbrtchx@gmail.com> - 2023-12-20 08:50 +0100
Re: difference in seconds between two formatted dates ... Greg Wooledge <greg@wooledge.org> - 2023-12-20 13:20 +0100
Re: difference in seconds between two formatted dates ... <tomas@tuxteam.de> - 2023-12-20 13:40 +0100
Re: difference in seconds between two formatted dates ... Albretch Mueller <lbrtchx@gmail.com> - 2023-12-20 14:20 +0100
Re: difference in seconds between two formatted dates ... <tomas@tuxteam.de> - 2023-12-20 14:40 +0100
Re: difference in seconds between two formatted dates ... Greg Wooledge <greg@wooledge.org> - 2023-12-20 16:10 +0100
Re: difference in seconds between two formatted dates ... Nicolas George <george@nsup.org> - 2023-12-20 16:30 +0100
systemd and timezone (was: Re: difference in seconds between two formatted dates ...) Max Nikulin <manikulin@gmail.com> - 2023-12-21 04:50 +0100
Re: systemd and timezone (was: Re: difference in seconds between two formatted dates ...) <tomas@tuxteam.de> - 2023-12-21 07:00 +0100
Re: systemd and timezone Max Nikulin <manikulin@gmail.com> - 2023-12-21 17:10 +0100
Re: systemd and timezone Nicholas Geovanis <nickgeovanis@gmail.com> - 2023-12-22 02:00 +0100
Re: systemd and timezone Andy Smith <andy@strugglers.net> - 2023-12-22 13:50 +0100
Re: systemd and timezone (was: Re: difference in seconds between two formatted dates ...) Jeffrey Walton <noloader@gmail.com> - 2023-12-21 17:30 +0100
Re: systemd and timezone (was: Re: difference in seconds between two formatted dates ...) tomas@tuxteam.de - 2023-12-21 18:40 +0100
Re: systemd and timezone (was: Re: difference in seconds between two formatted dates ...) Dan Ritter <dsr@randomstring.org> - 2023-12-21 15:30 +0100
Re: systemd and timezone (was: Re: difference in seconds between two formatted dates ...) <tomas@tuxteam.de> - 2023-12-21 16:10 +0100
Re: systemd and timezone (was: Re: difference in seconds between two formatted dates ...) Nicolas George <george@nsup.org> - 2023-12-21 23:00 +0100
Re: systemd and timezone gene heskett <gheskett@shentel.net> - 2023-12-22 01:00 +0100
Re: systemd and timezone Max Nikulin <manikulin@gmail.com> - 2023-12-22 13:50 +0100
Re: systemd and timezone <tomas@tuxteam.de> - 2023-12-22 14:40 +0100
Re: systemd and timezone Greg Wooledge <greg@wooledge.org> - 2023-12-22 15:20 +0100
Re: systemd and timezone David Wright <deblis@lionunicorn.co.uk> - 2023-12-22 16:50 +0100
Re: systemd and timezone Greg Wooledge <greg@wooledge.org> - 2023-12-22 17:30 +0100
Re: systemd and timezone "Arno Lehmann, ITS" <al@its-lehmann.de> - 2023-12-22 20:20 +0100
Re: systemd and timezone Greg Wooledge <greg@wooledge.org> - 2023-12-22 21:00 +0100
Re: systemd and timezone David Wright <deblis@lionunicorn.co.uk> - 2023-12-22 20:50 +0100
Re: systemd and timezone Greg Wooledge <greg@wooledge.org> - 2023-12-22 21:20 +0100
Re: systemd and timezone David Wright <deblis@lionunicorn.co.uk> - 2023-12-23 07:20 +0100
Re: systemd and timezone Sven Joachim <svenjoac@gmx.de> - 2023-12-22 21:20 +0100
Re: systemd and timezone Greg Wooledge <greg@wooledge.org> - 2023-12-22 22:40 +0100
Re: systemd and timezone David Wright <deblis@lionunicorn.co.uk> - 2023-12-23 00:30 +0100
Re: systemd and timezone Pocket <pocket@columbus.rr.com> - 2023-12-23 00:50 +0100
Re: systemd and timezone Pocket <pocket@columbus.rr.com> - 2023-12-23 01:10 +0100
Re: systemd and timezone David Wright <deblis@lionunicorn.co.uk> - 2023-12-23 07:20 +0100
Re: Support for SysV service scripts deprecated in systemd 255 (was: systemd and timezone) Felix Miata <mrmazda@earthlink.net> - 2023-12-23 08:10 +0100
Re: systemd and timezone Pocket <pocket@columbus.rr.com> - 2023-12-23 12:10 +0100
Re: systemd and timezone Nate Bargmann <n0nb@n0nb.us> - 2023-12-23 02:00 +0100
Re: systemd and timezone Greg Wooledge <greg@wooledge.org> - 2023-12-23 02:20 +0100
Re: systemd and timezone <tomas@tuxteam.de> - 2023-12-22 17:10 +0100
Re: systemd and timezone Jeffrey Walton <noloader@gmail.com> - 2023-12-22 21:00 +0100
Re: systemd and timezone Nicolas George <george@nsup.org> - 2023-12-22 23:40 +0100
Re: systemd and timezone Charles Kroeger <mbone@gmx.co.uk> - 2024-01-06 03:30 +0100
Re: systemd and timezone Greg Wooledge <greg@wooledge.org> - 2024-01-06 05:30 +0100
Re: systemd and timezone gene heskett <gheskett@shentel.net> - 2024-01-06 06:40 +0100
tzdata-legacy [was: Re: systemd and timezone] Max Nikulin <manikulin@gmail.com> - 2024-01-06 07:20 +0100
Re: tzdata-legacy [was: Re: systemd and timezone] Max Nikulin <manikulin@gmail.com> - 2024-01-06 08:10 +0100
Re: tzdata-legacy [was: Re: systemd and timezone] Nate Bargmann <n0nb@n0nb.us> - 2024-01-06 10:20 +0100
Re: tzdata-legacy [was: Re: systemd and timezone] gene heskett <gheskett@shentel.net> - 2024-01-06 13:10 +0100
Re: tzdata-legacy [was: Re: systemd and timezone] Greg Wooledge <greg@wooledge.org> - 2024-01-06 16:10 +0100
Re: tzdata-legacy [was: Re: systemd and timezone] David Wright <deblis@lionunicorn.co.uk> - 2024-01-07 18:30 +0100
was: Re: tzdata-legacy [was: Re: systemd and timezone] gene heskett <gheskett@shentel.net> - 2024-01-06 13:00 +0100
Re: was: Re: tzdata-legacy [was: Re: systemd and timezone] John Hasler <john@sugarbit.com> - 2024-01-06 15:30 +0100
SOLVED FOR GENE:Re: was: Re: tzdata-legacy [was: Re: systemd and timezone] gene heskett <gheskett@shentel.net> - 2024-01-06 20:10 +0100
Re: SOLVED FOR GENE:Re: was: Re: tzdata-legacy [was: Re: systemd and timezone] John Hasler <john@sugarbit.com> - 2024-01-06 20:40 +0100
Re: SOLVED FOR GENE:Re: was: Re: tzdata-legacy [was: Re: systemdand timezone] gene heskett <gheskett@shentel.net> - 2024-01-06 21:40 +0100
Re: SOLVED FOR GENE:Re: was: Re: tzdata-legacy [was: Re: systemdand timezone] Nate Bargmann <n0nb@n0nb.us> - 2024-01-06 23:10 +0100
Re: SOLVED FOR GENE:Re: was: Re: tzdata-legacy [was: Re: systemdand timezone] Greg Wooledge <greg@wooledge.org> - 2024-01-07 01:10 +0100
Re: SOLVED FOR GENE:Re: was: Re: tzdata-legacy [was: Re: systemdandtimezone] gene heskett <gheskett@shentel.net> - 2024-01-07 05:30 +0100
Re: SOLVED FOR GENE:Re: was: Re: tzdata-legacy [was: Re: systemdandtimezone] Nate Bargmann <n0nb@n0nb.us> - 2024-01-07 12:30 +0100
Re: SOLVED FOR GENE Felix Miata <mrmazda@earthlink.net> - 2024-01-07 12:40 +0100
Re: SOLVED FOR GENE jeremy ardley <jeremy.ardley@gmail.com> - 2024-01-07 13:10 +0100
Re: SOLVED FOR GENE john doe <johndoe65534@mail.com> - 2024-01-07 13:40 +0100
Re: SOLVED FOR GENE Michael Stone <mstone@debian.org> - 2024-01-11 14:30 +0100
Re: SOLVED FOR GENE Felix Miata <mrmazda@earthlink.net> - 2024-01-11 18:10 +0100
manpages package [WAS Re: SOLVED FOR GENE:Re: was: Re: tzdata-legacy [was: Re: systemd and timezone] "Andrew M.A. Cater" <amacater@einval.com> - 2024-01-06 23:50 +0100
Re: was: Re: tzdata-legacy [was: Re: systemd and timezone] Max Nikulin <manikulin@gmail.com> - 2024-01-06 18:10 +0100
Re: was: Re: tzdata-legacy [was: Re: systemd and timezone] gene heskett <gheskett@shentel.net> - 2024-01-06 20:40 +0100
systemd-timesyncd Max Nikulin <manikulin@gmail.com> - 2024-01-07 16:50 +0100
Re: systemd-timesyncd John Hasler <john@sugarbit.com> - 2024-01-07 17:30 +0100
Re: systemd-timesyncd gene heskett <gheskett@shentel.net> - 2024-01-07 21:20 +0100
Re: systemd-timesyncd Charles Kroeger <mbone@gmx.co.uk> - 2024-01-08 06:50 +0100
Re: systemd-timesyncd gene heskett <gheskett@shentel.net> - 2024-01-07 21:10 +0100
Re: systemd-timesyncd "Andrew M.A. Cater" <amacater@einval.com> - 2024-01-07 22:00 +0100
Re: systemd-timesyncd Charles Curley <charlescurley@charlescurley.com> - 2024-01-08 00:00 +0100
Re: systemd-timesyncd Nicholas Geovanis <nickgeovanis@gmail.com> - 2024-01-08 01:40 +0100
VAX emulation/simulation (was Re: systemd-timesyncd) The Wanderer <wanderer@fastmail.fm> - 2024-01-08 02:10 +0100
Re: VAX emulation/simulation (was Re: systemd-timesyncd) Bret Busby <bret@busby.net> - 2024-01-08 10:40 +0100
Re: VAX emulation/simulation (was Re: systemd-timesyncd) "Jeremy Nicoll" <jn.ml.dbi.73@letterboxes.org> - 2024-01-08 11:40 +0100
Re: VAX emulation/simulation (was Re: systemd-timesyncd) "Thomas Schmitt" <scdbackup@gmx.net> - 2024-01-08 13:20 +0100
Re: VAX emulation/simulation (was Re: systemd-timesyncd) Nicholas Geovanis <nickgeovanis@gmail.com> - 2024-01-09 01:00 +0100
Re: VAX emulation/simulation (was Re: systemd-timesyncd) "Thomas Schmitt" <scdbackup@gmx.net> - 2024-01-09 09:20 +0100
Re: VAX emulation/simulation (was Re: systemd-timesyncd) Bret Busby <bret@busby.net> - 2024-01-09 10:40 +0100
Re: VAX emulation/simulation (was Re: systemd-timesyncd) "Thomas Schmitt" <scdbackup@gmx.net> - 2024-01-09 11:20 +0100
Re: VAX emulation/simulation (was Re: systemd-timesyncd) Nicolas George <george@nsup.org> - 2024-01-09 11:40 +0100
Re: VAX emulation/simulation (was Re: systemd-timesyncd) gene heskett <gheskett@shentel.net> - 2024-01-09 12:30 +0100
Re: VAX emulation/simulation (was Re: systemd-timesyncd) "Niall O'Reilly" <niall+lists@no8.be> - 2024-01-08 21:50 +0100
Re: systemd-timesyncd gene heskett <gheskett@shentel.net> - 2024-01-08 16:00 +0100
Re: systemd-timesyncd gene heskett <gheskett@shentel.net> - 2024-01-08 16:00 +0100
Re: systemd-timesyncd Max Nikulin <manikulin@gmail.com> - 2024-01-08 04:40 +0100
Re: systemd-timesyncd Curt <curty@free.fr> - 2024-01-08 18:00 +0100
Re: systemd-timesyncd Max Nikulin <manikulin@gmail.com> - 2024-01-08 04:20 +0100
Re: systemd-timesyncd Charles Curley <charlescurley@charlescurley.com> - 2024-01-08 05:10 +0100
Re: systemd-timesyncd Mark Fletcher <mark27q1@gmail.com> - 2024-01-08 14:50 +0100
mktime (was: Re: systemd and timezone) Max Nikulin <manikulin@gmail.com> - 2023-12-23 18:00 +0100
Re: mktime (was: Re: systemd and timezone) Jeffrey Walton <noloader@gmail.com> - 2023-12-23 19:30 +0100
Re: mktime Max Nikulin <manikulin@gmail.com> - 2023-12-24 03:40 +0100
Re: mktime (was: Re: systemd and timezone) <tomas@tuxteam.de> - 2023-12-24 08:40 +0100
Re: mktime Max Nikulin <manikulin@gmail.com> - 2023-12-28 03:40 +0100
Re: systemd and timezone Max Nikulin <manikulin@gmail.com> - 2023-12-21 16:30 +0100
Re: difference in seconds between two formatted dates ... Max Nikulin <manikulin@gmail.com> - 2023-12-22 03:20 +0100
Re: difference in seconds between two formatted dates ... <tomas@tuxteam.de> - 2023-12-22 08:00 +0100
Re: difference in seconds between two formatted dates ... David Wright <deblis@lionunicorn.co.uk> - 2023-12-21 05:40 +0100
Re: difference in seconds between two formatted dates ... Max Nikulin <manikulin@gmail.com> - 2023-12-21 06:50 +0100
Re: difference in seconds between two formatted dates ... Albretch Mueller <lbrtchx@gmail.com> - 2023-12-21 07:10 +0100
Re: difference in seconds between two formatted dates ... <tomas@tuxteam.de> - 2023-12-21 08:10 +0100
Re: difference in seconds between two formatted dates ... Greg Wooledge <greg@wooledge.org> - 2023-12-21 13:40 +0100
Re: difference in seconds between two formatted dates ... Max Nikulin <manikulin@gmail.com> - 2023-12-21 16:40 +0100
Re: difference in seconds between two formatted dates ... Greg Wooledge <greg@wooledge.org> - 2023-12-21 19:30 +0100
Re: difference in seconds between two formatted dates ... gene heskett <gheskett@shentel.net> - 2023-12-21 21:00 +0100
Re: difference in seconds between two formatted dates ... Greg Wooledge <greg@wooledge.org> - 2023-12-21 21:10 +0100
Re: difference in seconds between two formatted dates ... gene heskett <gheskett@shentel.net> - 2023-12-21 21:40 +0100
Re: difference in seconds between two formatted dates ... Greg Wooledge <greg@wooledge.org> - 2023-12-21 22:40 +0100
Re: difference in seconds between two formatted dates ... gene heskett <gheskett@shentel.net> - 2023-12-22 00:40 +0100
Re: difference in seconds between two formatted dates ... Albretch Mueller <lbrtchx@gmail.com> - 2023-12-25 16:40 +0100
Re: difference in seconds between two formatted dates ... Greg Wooledge <greg@wooledge.org> - 2023-12-25 18:40 +0100
Re: difference in seconds between two formatted dates ... Albretch Mueller <lbrtchx@gmail.com> - 2023-12-26 08:00 +0100
Re: difference in seconds between two formatted dates ... "Thomas Schmitt" <scdbackup@gmx.net> - 2023-12-26 08:30 +0100
Re: difference in seconds between two formatted dates ... Albretch Mueller <lbrtchx@gmail.com> - 2023-12-26 16:00 +0100
Re: difference in seconds between two formatted dates ... Greg Wooledge <greg@wooledge.org> - 2023-12-26 16:40 +0100
Re: difference in seconds between two formatted dates ... Albretch Mueller <lbrtchx@gmail.com> - 2023-12-26 19:40 +0100
Re: difference in seconds between two formatted dates ... Greg Wooledge <greg@wooledge.org> - 2023-12-26 22:40 +0100
Re: difference in seconds between two formatted dates ... Albretch Mueller <lbrtchx@gmail.com> - 2023-12-27 01:40 +0100
Re: difference in seconds between two formatted dates ... Greg Wooledge <greg@wooledge.org> - 2023-12-27 01:50 +0100
When strace breaks process or is blocked (was: Re: difference in seconds between two formatted dates ...) Max Nikulin <manikulin@gmail.com> - 2023-12-27 17:50 +0100
Re: difference in seconds between two formatted dates ... Max Nikulin <manikulin@gmail.com> - 2023-12-18 03:30 +0100
Re: difference in seconds between two formatted dates ... Albretch Mueller <lbrtchx@gmail.com> - 2023-12-25 00:10 +0100
Re: difference in seconds between two formatted dates ... David Wright <deblis@lionunicorn.co.uk> - 2023-12-25 01:10 +0100
Re: difference in seconds between two formatted dates ... Albretch Mueller <lbrtchx@gmail.com> - 2023-12-25 01:30 +0100
Re: difference in seconds between two formatted dates ... Greg Wooledge <greg@wooledge.org> - 2023-12-25 02:20 +0100
Re: difference in seconds between two formatted dates ... "Andrew M.A. Cater" <amacater@einval.com> - 2023-12-25 11:40 +0100
Re: difference in seconds between two formatted dates ... Tixy <tixy@yxit.co.uk> - 2023-12-25 09:10 +0100
Re: difference in seconds between two formatted dates ... Andy Smith <andy@strugglers.net> - 2023-12-27 00:00 +0100
Re: difference in seconds between two formatted dates ... Greg Wooledge <greg@wooledge.org> - 2023-12-17 19:00 +0100
Re: difference in seconds between two formatted dates ... David Wright <deblis@lionunicorn.co.uk> - 2023-12-17 19:30 +0100
Re: difference in seconds between two formatted dates ... Teemu Likonen <tlikonen@iki.fi> - 2023-12-17 12:50 +0100
Re: difference in seconds between two formatted dates ... <tomas@tuxteam.de> - 2023-12-17 12:10 +0100
Re: difference in seconds between two formatted dates ... Greg Wooledge <greg@wooledge.org> - 2023-12-17 15:10 +0100
Page 8 of 9 — ← Prev page 1 2 3 4 5 6 7 [8] 9 Next page →
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2023-12-21 22:40 +0100 |
| Message-ID | <HNyVP-favU-11@gated-at.bofh.it> |
| In reply to | #265114 |
On Thu, Dec 21, 2023 at 03:34:49PM -0500, gene heskett wrote: > unforch it does not create them and in my recent experience it may run but > does not work without being able to log. That would be a bug, given that this stats directory is apparently optional. (It logs through syslog just fine without the stats dir.) What evidence did you see that makes you think it wasn't working?
[toc] | [prev] | [next] | [standalone]
| From | gene heskett <gheskett@shentel.net> |
|---|---|
| Date | 2023-12-22 00:40 +0100 |
| Message-ID | <HNANX-fbG9-3@gated-at.bofh.it> |
| In reply to | #265117 |
On 12/21/23 16:31, Greg Wooledge wrote: > On Thu, Dec 21, 2023 at 03:34:49PM -0500, gene heskett wrote: >> unforch it does not create them and in my recent experience it may run but >> does not work without being able to log. > > That would be a bug, given that this stats directory is apparently > optional. (It logs through syslog just fine without the stats dir.) > > What evidence did you see that makes you think it wasn't working? > > . A nominal +12 minute error was not corrected despite several restarts of ntpsec. Reading the .conf it finally dawned that I did not have that directory, so I made it, chowned it to ntpsec:ntpsec and by the time I had looked to see the that it was using that dir, I found the clock was by then about .0017 microseconds off. Serendipity? DarnedifIknow. Take care, stay warm and well, Greg. Cheers, Gene Heskett. -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author, 1940) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis
[toc] | [prev] | [next] | [standalone]
| From | Albretch Mueller <lbrtchx@gmail.com> |
|---|---|
| Date | 2023-12-25 16:40 +0100 |
| Message-ID | <HOVdD-g3pI-1@gated-at.bofh.it> |
| In reply to | #265066 |
On 12/21/23, Greg Wooledge <greg@wooledge.org> wrote: > So... this is interesting. Apparently timedatectl doesn't simply look > at the target of /etc/localtime. There's a DELAY before the value is > correctly reported. This tells me that timedatectl is in communication > with some process (perhaps PID 1, I don't know), and this other process > only discovers that /etc/localtime has changed after some time has passed. > Is it *polling*? I have no idea, but that's what it looks like. This thread has taken a life of its own and I have learned quite a bit from our back and forth. This is not how I intuitively thought it worked. I thought you had to actively ask the OS to update itself ... Now I am interested in learning all there is to be learned from this whole time keeping methodology and how it relates to systemd and the boot process. Is there a way to start the Linux kernel of a Debian Live running instance enabling you to log the whole process (in a more in depth way than dmesg) and then go "follow tcp" for each listed process in dmesg as you do with wireshark? lbrtchx
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2023-12-25 18:40 +0100 |
| Message-ID | <HOX5M-g4wx-9@gated-at.bofh.it> |
| In reply to | #265249 |
On Mon, Dec 25, 2023 at 03:35:04PM +0000, Albretch Mueller wrote: > On 12/21/23, Greg Wooledge <greg@wooledge.org> wrote: > > So... this is interesting. Apparently timedatectl doesn't simply look > > at the target of /etc/localtime. There's a DELAY before the value is > > correctly reported. This tells me that timedatectl is in communication > > with some process (perhaps PID 1, I don't know), and this other process > > only discovers that /etc/localtime has changed after some time has passed. > > Is it *polling*? I have no idea, but that's what it looks like. > > This thread has taken a life of its own and I have learned quite a > bit from our back and forth. This is not how I intuitively thought it > worked. I thought you had to actively ask the OS to update itself ... > Now I am interested in learning all there is to be learned from this > whole time keeping methodology and how it relates to systemd and the > boot process. Be sure to read the other responses to that message. There's a weird timing issue caused by the fact that running "timedatectl" triggers a service process to run, unless one is already running. This service process only stays running for 30 seconds, and it only reads the /etc/localtime symlink when it starts up. So, if you've already got one running, it won't pick up a changed /etc/localtime. But if you wait until the current one dies, then the *next* one will. I have no idea why this subsystem was designed to work this way. It seems awkward to me, but I'll give them the benefit of the doubt for now -- there's probably *some* reason to do it this way, even if it's not immediately clear to me. > Is there a way to start the Linux kernel of a Debian Live running > instance enabling you to log the whole process (in a more in depth way > than dmesg) and then go "follow tcp" for each listed process in dmesg > as you do with wireshark? If you want to see what a process is doing, there's strace. It can even be told to follow all the children of a process (strace -f).
[toc] | [prev] | [next] | [standalone]
| From | Albretch Mueller <lbrtchx@gmail.com> |
|---|---|
| Date | 2023-12-26 08:00 +0100 |
| Message-ID | <HP9zX-gbQe-1@gated-at.bofh.it> |
| In reply to | #265250 |
On 12/25/23, Greg Wooledge <greg@wooledge.org> wrote: > If you want to see what a process is doing, there's strace. It can > even be told to follow all the children of a process (strace -f). But how do you strace a program saving the output (of the stracing) in a logfile while you also save that program's output without making it part of the stracing? Say you go: $ strace -f wget --help You can clearly see the output of "wget --help" tailgated as part of the stracing (which, of course, you can parse out), but I want two separate log files. One for the stracing and the other for the actual output of that program you ran. I found some posts suggesting that to be possible, but I couldn't get it right: https://serverfault.com/questions/205498/how-to-get-pid-of-just-started-process https://askubuntu.com/questions/137233/how-to-command-ping-display-time-and-date-of-ping/867500#867500 lbrtchx
[toc] | [prev] | [next] | [standalone]
| From | "Thomas Schmitt" <scdbackup@gmx.net> |
|---|---|
| Date | 2023-12-26 08:30 +0100 |
| Message-ID | <HPa2Z-gcek-1@gated-at.bofh.it> |
| In reply to | #265262 |
Hi,
Albretch Mueller wrote:
> But how do you strace a program saving the output (of the stracing)
> in a logfile while you also save that program's output without making
> it part of the stracing?
man strace says:
-o filename Write the trace output to the file filename rather
than to stderr.
So strace normally directs its output to stderr. That's file descriptor 2.
You can redirect it by the "2>file" gesture of the shell:
$ strace echo hello 2>file
hello
$ cat file
execve("/bin/echo", ["echo"], [/* 35 vars */]) = 0
brk(0) = 0x13ba000
...
exit_group(0) = ?
+++ exited with 0 +++
Or you may use the mentioned -o option which will keep the tracee's stderr
out of the file:
$ strace -o file echo hello
hello
$ cat file
...
Have a nice day :)
Thomas
[toc] | [prev] | [next] | [standalone]
| From | Albretch Mueller <lbrtchx@gmail.com> |
|---|---|
| Date | 2023-12-26 16:00 +0100 |
| Message-ID | <HPh4u-ggtK-7@gated-at.bofh.it> |
| In reply to | #265263 |
On 12/26/23, Thomas Schmitt <scdbackup@gmx.net> wrote:
> man strace says:
> -o filename Write the trace output to the file filename rather
> than to stderr.
>
> So strace normally directs its output to stderr. That's file descriptor 2.
> You can redirect it by the "2>file" gesture of the shell:
>
> $ strace echo hello 2>file
> hello
> $ cat file
> execve("/bin/echo", ["echo"], [/* 35 vars */]) = 0
> brk(0) = 0x13ba000
> ...
> exit_group(0) = ?
> +++ exited with 0 +++
>
> Or you may use the mentioned -o option which will keep the tracee's stderr
> out of the file:
>
> $ strace -o file echo hello
> hello
> $ cat file
> ...
three questions:
1) how do you set up the process to be straced as a parameter? Something like:
prx="echo hello"
logfile="file.txt"
#
strace "${prx}" 2>"${logfile}"
ls -l "${logfile}"; wc -l "${logfile}"; cat "${logfile}"
2) how do you know for sure that you are stracing the same process
that you are running and is logging some data? I had read up from the
links that I included that there are ways to make the shell spit the
process number before a process is run, but how do you then insert the
stracing segment in the one liner in order the use that process id
before the process is actually run?
The way I understand the PID options of strace:
strace --help ...
-p PID, --attach=PID: trace process with process id PID, may be repeated
--tips[=[[id:]ID][,[format:]FORMAT]]: show strace tips, tricks, and
tweaks on exit
id: non-negative integer or random; default is random
format: none, compact, full; default is compact
it seems to be attaching to some already running deamon or server process.
How do you make it swallow a process that would go in one step/moment?
3) I have noticed that strace output is not totally predictable, so
"parsing" is not that safe, straightforward
prx="echo hello"
logfile="file.txt"
#
strace "${prx}" 2>"${logfile}"
ls -l "${logfile}"; wc -l "${logfile}"; cat "${logfile}"
$ strace file strace.wlog.txt 2>&1 | tail -n 5
write(1, "strace.wlog.txt: ASCII text, wit"..., 56strace.wlog.txt:
ASCII text, with very long lines (348)
) = 56
munmap(0x7f127f083000, 8281024) = 0
exit_group(0) = ?
+++ exited with 0 +++
$ strace wget --help 2>&1 | tail -n 5
Email bug reports, questions, discussions to <bug-wget@gnu.org>
and/or open issues at https://savannah.gnu.org/bugs/?func=additem&group=wget.
) = 956
exit_group(0) = ?
+++ exited with 0 +++
$
Notice the diffing "munmap(0x7f127f083000, 8281024) = 0" line
which I think comes from strace.
lbrtchc
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2023-12-26 16:40 +0100 |
| Message-ID | <HPhHb-ggVJ-5@gated-at.bofh.it> |
| In reply to | #265268 |
On Tue, Dec 26, 2023 at 02:57:54PM +0000, Albretch Mueller wrote:
> 1) how do you set up the process to be straced as a parameter? Something like:
> prx="echo hello"
> logfile="file.txt"
> #
> strace "${prx}" 2>"${logfile}"
> ls -l "${logfile}"; wc -l "${logfile}"; cat "${logfile}"
Why? This does not appear to have any usefulness. You're just making
your life harder for no reason.
See also <https://mywiki.wooledge.org/BashFAQ/050>.
> 2) how do you know for sure that you are stracing the same process
> that you are running and is logging some data?
You are EXTREMELY confused about something, and we NEED to address this
immediately.
If you run "strace ./foo", a new instance of ./foo is launched right
then and there, and you get the system call trace of THAT instance.
If another instance of ./foo was already running, you do NOT get the
system call trace of that first instance.
If you WANT the system call trace of an ALREADY-RUNNING PROCESS, you
need to get its process ID (PID) and use strace's "-p pid" option to
CONNECT to the existing process and begin tracing it.
That will not give you past system calls from the already-running
process. What's done is done. It will only give you system calls
that are made from that point forward.
> The way I understand the PID options of strace:
>
> it seems to be attaching to some already running deamon or server process.
Yes. If that's what you want.
> How do you make it swallow a process that would go in one step/moment?
Don't use -p. -p connects to an existing PID. Without -p you create a
whole new process.
> 3) I have noticed that strace output is not totally predictable, so
> "parsing" is not that safe, straightforward
It's not meant to be parsed. It's meant to be read by YOU, as part of
your debugging or diagnostics. You use this tool when you want information
that nothing else will give you.
The strace output is long, detailed, and difficult to understand. It
will take some practice to learn how to interpret it.
> $ strace wget --help 2>&1 | tail -n 5
> Email bug reports, questions, discussions to <bug-wget@gnu.org>
> and/or open issues at https://savannah.gnu.org/bugs/?func=additem&group=wget.
> ) = 956
> exit_group(0) = ?
> +++ exited with 0 +++
> $
You're talking about timing and buffering issues here. If these are
a concern, don't use stderr. Use strace's -o option to log the trace
to a logfile. That way it will not intermix with the program's standard
output and standard error.
Remember that standard output, when NOT going to a terminal, is usually
buffered. In your example there, you've got wget's output going to a pipe
(which is not a terminal), so it gets buffered. This can cause weird
artifacts, if you were expecting each line to be visible immediately for
example. Even worse, you've got wget's stdout and stderr, and strace's
stderr, all mixed together into a single stream, with who-knows-what
kind of buffering on each component.
[toc] | [prev] | [next] | [standalone]
| From | Albretch Mueller <lbrtchx@gmail.com> |
|---|---|
| Date | 2023-12-26 19:40 +0100 |
| Message-ID | <HPkvo-giB1-9@gated-at.bofh.it> |
| In reply to | #265269 |
On 12/26/23, Greg Wooledge <greg@wooledge.org> wrote:
> On Tue, Dec 26, 2023 at 02:57:54PM +0000, Albretch Mueller wrote:
>> 1) how do you set up the process to be straced as a parameter? Something
>> like:
>> prx="echo hello"
>> logfile="file.txt"
>> #
>> strace "${prx}" 2>"${logfile}"
>> ls -l "${logfile}"; wc -l "${logfile}"; cat "${logfile}"
>
> Why? This does not appear to have any usefulness. You're just making
> your life harder for no reason.
Well, the way I see such my options, you could:
1.1) parametrize a call to a function, or
1.2) use named files for each type of strace run.
I would rather use Ā§1.1
> See also <https://mywiki.wooledge.org/BashFAQ/050>.
Thank you. As you have suggested to me. I will have to use a
highlevel language if I want to take care of my "coblesome" cases. I
tend to entangle myself in corner cases for which scripts aren't so
useful.
>> 2) how do you know for sure that you are stracing the same process
>> that you are running and is logging some data?
>
> You are EXTREMELY confused about something, and we NEED to address this
> immediately.
>
> If you run "strace ./foo", a new instance of ./foo is launched right
> then and there, and you get the system call trace of THAT instance.
Based on:
https://askubuntu.com/questions/137233/how-to-command-ping-display-time-and-date-of-ping/867500
I think I am getting close to where I need to with this (am I?):
$ bash -c 'ping www.google.fr -c 4 &'; echo "Caller PID: $$"; strace -p $$
Caller PID: 45588
strace: Process 45588 attached
wait4(-1, PING www.google.fr (142.250.190.131) 56(84) bytes of data.
64 bytes from ord37s36-in-f3.1e100.net (142.250.190.131): icmp_seq=1
ttl=54 time=50.0 ms
64 bytes from ord37s36-in-f3.1e100.net (142.250.190.131): icmp_seq=2
ttl=54 time=34.7 ms
64 bytes from ord37s36-in-f3.1e100.net (142.250.190.131): icmp_seq=3
ttl=54 time=38.7 ms
64 bytes from ord37s36-in-f3.1e100.net (142.250.190.131): icmp_seq=4
ttl=54 time=40.3 ms
--- www.google.fr ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3004ms
rtt min/avg/max/mdev = 34.735/40.952/50.048/5.628 ms
^Cstrace: Process 45588 detached
<detached ...>
$
However, strace doesn't end gracefully even though it seems to attach
to the running process before it starts and based on what strace
itself logs, the process seems to end just fine.
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2023-12-26 22:40 +0100 |
| Message-ID | <HPnjB-gkhg-29@gated-at.bofh.it> |
| In reply to | #265279 |
On Tue, Dec 26, 2023 at 06:31:19PM +0000, Albretch Mueller wrote:
> I think I am getting close to where I need to with this (am I?):
>
> $ bash -c 'ping www.google.fr -c 4 &'; echo "Caller PID: $$"; strace -p $$
I don't understand what you're trying to do here. Is this an
oversimplified example that has been so twisted and distorted that we
can't tell what the point is?
If you want to strace a ping process, just use:
strace ping www.google.fr -c 4
There is no reason to invoke a second shell, nor to run the ping process
in the background, nor to use strace on an already-started ping
process.
Even if you DID for some reason want to launch a BACKGROUND PROCESS and
the strace it, you're doing it wrong. The $$ you reference in your
strace command is the PID of the script. Your bash -c is a child of
the script, and your ping is a child of the bash -c (thus, a grandchild
of the script).
If you want to launch a SIMPLE BACKGROUND PROCESS (note the SIMPLE here,
this is IMPORTANT), and then strace it while it runs, you'd do it like
this:
ping www.google.fr -c 4 &
pid=$!
strace -p "$pid"
wait "$pid"
Note that there is no "bash -c". This is IMPORTANT. The ping process
is a direct child of the script. That's why we can get its PID with
the $! special parameter, after launching it with & into the background.
If the thing you're trying to strace is actually a COMPLEX DAEMON that
does its own forking and shit, then this MAY NOT WORK. You could
attempt to attach strace to the daemon's original PID, but if the daemon
forks and then commits suicide (a VERY OUTDATED design), then your
strace may be too late. It might be trying to attach to a process
that's already dead.
If the thing you're trying to strace is a long-running daemon that
forks child process but DOES NOT kill itself, then it MIGHT work.
You'd want the "-f" option to trace all child processes as well as
the main PID.
Now, you see, we cannot tell from your "ping" or "bash -c ping" example
what it is that you're ACTUALLY trying to attach to. What is it
REALLY? How does it behave? What information are you trying to
capture in your strace?
What PROBLEM are you even trying to solve?
Why are you writing a SCRIPT to solve your problem instead of running
an strace command by hand to get a one-off trace log so that you can
analyze it?
(Oh, also, just to add more bruises on the dead horse, ping is sometimes
a setuid root program. Depends on the OS. If it's setuid root on your
system, you might not be able to strace it without being root to start
with.)
[toc] | [prev] | [next] | [standalone]
| From | Albretch Mueller <lbrtchx@gmail.com> |
|---|---|
| Date | 2023-12-27 01:40 +0100 |
| Message-ID | <HPq7L-glTP-1@gated-at.bofh.it> |
| In reply to | #265284 |
On 12/26/23, Greg Wooledge <greg@wooledge.org> wrote:
> If you want to launch a SIMPLE BACKGROUND PROCESS (note the SIMPLE here,
> this is IMPORTANT), and then strace it while it runs, you'd do it like
> this:
>
> ping www.google.fr -c 4 &
> pid=$!
> strace -p "$pid"
> wait "$pid"
I am getting an "Operation not permitted" error while strace tries to
attach to that pid:
"strace: attach: ptrace(PTRACE_SEIZE, 52527): Operation not permitted"
$ ping www.google.fr -c 4 &
pid=$!
strace -p "$pid"
wait "$pid"
[1] 52527
strace: attach: ptrace(PTRACE_SEIZE, 52527): Operation not permitted
PING www.google.fr (64.233.185.94) 56(84) bytes of data.
64 bytes from yb-in-f94.1e100.net (64.233.185.94): icmp_seq=1 ttl=55
time=54.2 ms
64 bytes from yb-in-f94.1e100.net (64.233.185.94): icmp_seq=2 ttl=55
time=61.3 ms
64 bytes from yb-in-f94.1e100.net (64.233.185.94): icmp_seq=3 ttl=55
time=60.5 ms
64 bytes from yb-in-f94.1e100.net (64.233.185.94): icmp_seq=4 ttl=55 time=125 ms
--- www.google.fr ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 54.240/75.219/124.823/28.769 ms
[1]+ Done ping www.google.fr -c 4
$
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2023-12-27 01:50 +0100 |
| Message-ID | <HPqhr-glWT-1@gated-at.bofh.it> |
| In reply to | #265289 |
On Wed, Dec 27, 2023 at 12:39:26AM +0000, Albretch Mueller wrote: > I am getting an "Operation not permitted" error while strace tries to > attach to that pid: > > "strace: attach: ptrace(PTRACE_SEIZE, 52527): Operation not permitted" > > > $ ping www.google.fr -c 4 & > pid=$! > strace -p "$pid" > wait "$pid" Yeah, even on Debian systems where ping isn't setuid root, it still seems to need special capabilities that strace interferes with, or isn't allowed to attach to, or something. unicorn:~$ strace -o log ping www.debian.com -c 4 ping: socktype: SOCK_RAW ping: socket: Operation not permitted ping: => missing cap_net_raw+p capability or setuid? So, pick something other than ping, or run the strace as root.
[toc] | [prev] | [next] | [standalone]
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2023-12-27 17:50 +0100 |
| Subject | When strace breaks process or is blocked (was: Re: difference in seconds between two formatted dates ...) |
| Message-ID | <HPFgt-gv7Z-1@gated-at.bofh.it> |
| In reply to | #265290 |
On 27/12/2023 07:45, Greg Wooledge wrote: > Yeah, even on Debian systems where ping isn't setuid root, it still seems > to need special capabilities that strace interferes with, or isn't > allowed to attach to, or something. $ /usr/sbin/getcap /usr/bin/ping /usr/bin/ping cap_net_raw=ep It is still elevated privileges and they are dropped for traced processes to avoid malicious actions by the controlling process. SETGID may be a trick namely to avoid tracing: $ ls -l /usr/bin/ssh-agent -rwxr-sr-x 1 root _ssh 481664 Dec 19 21:51 /usr/bin/ssh-agent > So, pick something other than ping, or run the strace as root. Attaching by unprivileged processes to trace another process (strace -p PID) may be disabled using the following sysctl: kernel.yama.ptrace_scope = 1 For details see https://www.kernel.org/doc/html/latest/admin-guide/LSM/Yama.html In Ubuntu this security measure is enabled out of the box. In Debian higher priority was given to developers who may need to attach debugger to a running process. So it is not uncommon when tracing is blocked.
[toc] | [prev] | [next] | [standalone]
| From | Max Nikulin <manikulin@gmail.com> |
|---|---|
| Date | 2023-12-18 03:30 +0100 |
| Message-ID | <HMbyh-ejKb-1@gated-at.bofh.it> |
| In reply to | #264871 |
On 18/12/2023 06:00, Albretch Mueller wrote: > On 12/17/23, Andy Smith wrote: >>> how on earth would that not always produce an accurate duration? >> All this paranoia, but in computer time you trust? š >> Falsehoods programmers believe about time >> https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b923ca > and how does my paranoia relate to that wall of itemized statements > which could be reduced to just a few? Sources are given below that wall and they may be more pleasant to read. There are a lot of blog posts describing various pitfalls related to date and time. Timestamp format you have chosen is ambiguous. TZ=Europe/Berlin date -d '@1698539400' '+%Y%m%d%H%M%S' 20231029023000 TZ=Europe/Berlin date -d '@1698543000' '+%Y%m%d%H%M%S' 20231029023000 You had issues with setting time and timezone, so '+%s' may give incorrect results.
[toc] | [prev] | [next] | [standalone]
| From | Albretch Mueller <lbrtchx@gmail.com> |
|---|---|
| Date | 2023-12-25 00:10 +0100 |
| Message-ID | <HOFLz-fUh3-7@gated-at.bofh.it> |
| In reply to | #264875 |
On 12/18/23, Max Nikulin <manikulin@gmail.com> wrote: > Timestamp format you have chosen is ambiguous. > > TZ=Europe/Berlin date -d '@1698539400' '+%Y%m%d%H%M%S' > 20231029023000 > > TZ=Europe/Berlin date -d '@1698543000' '+%Y%m%d%H%M%S' > 20231029023000 > > You had issues with setting time and timezone, so '+%s' may give > incorrect results. Hmm! and one hour difference is not detected, because of the way is being parsed. Why would that happen? Why would %S be in the range second (00..60), instead of (00..59)?: seks00=1698539400; TZ=Europe/Berlin date -d '@1698539400' '+%Y%m%d%H%M%S' seks02=1698543000; TZ=Europe/Berlin date -d '@1698543000' '+%Y%m%d%H%M%S' diff_seks=$(( seks02 - seks00 )) echo "// __ \$diff_seks: |$diff_seks|" https://man7.org/linux/man-pages/man1/date.1.html %Y year %m month (01..12) %d day of month (e.g., 01) %H hour (00..23) %M minute (00..59) %S second (00..60) ~ C
[toc] | [prev] | [next] | [standalone]
| From | David Wright <deblis@lionunicorn.co.uk> |
|---|---|
| Date | 2023-12-25 01:10 +0100 |
| Message-ID | <HOGHD-fUOl-1@gated-at.bofh.it> |
| In reply to | #265234 |
On Sun 24 Dec 2023 at 23:05:53 (+0000), Albretch Mueller wrote: > On 12/18/23, Max Nikulin <manikulin@gmail.com> wrote: > > Timestamp format you have chosen is ambiguous. > > > > TZ=Europe/Berlin date -d '@1698539400' '+%Y%m%d%H%M%S' > > 20231029023000 > > > > TZ=Europe/Berlin date -d '@1698543000' '+%Y%m%d%H%M%S' > > 20231029023000 > > > > You had issues with setting time and timezone, so '+%s' may give > > incorrect results. > > Hmm! and one hour difference is not detected, because of the way is > being parsed. Why would that happen? Spring forward and fall backāthe clocks change, skipping an hour in spring and repeating an hour in autumn (Northern hemisphere). > Why would %S be in the range > second (00..60), instead of (00..59)?: Leap secondsāsee the example already in the thread: https://lists.debian.org/debian-user/2023/12/msg00976.html > seks00=1698539400; TZ=Europe/Berlin date -d '@1698539400' '+%Y%m%d%H%M%S' > > seks02=1698543000; TZ=Europe/Berlin date -d '@1698543000' '+%Y%m%d%H%M%S' > > diff_seks=$(( seks02 - seks00 )) > echo "// __ \$diff_seks: |$diff_seks|" > > https://man7.org/linux/man-pages/man1/date.1.html > %Y year > %m month (01..12) > %d day of month (e.g., 01) > %H hour (00..23) > %M minute (00..59) > %S second (00..60) Cheers, David.
[toc] | [prev] | [next] | [standalone]
| From | Albretch Mueller <lbrtchx@gmail.com> |
|---|---|
| Date | 2023-12-25 01:30 +0100 |
| Message-ID | <HOH0Z-fUUw-5@gated-at.bofh.it> |
| In reply to | #265235 |
On 12/25/23, David Wright <deblis@lionunicorn.co.uk> wrote: > On Sun 24 Dec 2023 at 23:05:53 (+0000), Albretch Mueller wrote: >> On 12/18/23, Max Nikulin <manikulin@gmail.com> wrote: ... >> Why would %S be in the range >> second (00..60), instead of (00..59)?: > > Leap secondsāsee the example already in the thread: > https://lists.debian.org/debian-user/2023/12/msg00976.html So, a possible (the only?) solution to those kinds of problems would be to always and explicitly use UTC, right? Or, using the longitude 20 West (just crossing Iceland, which is 60+ North) or 170 West (too close to "Vladimir Putin") where so few people live that I don't think that anyone would care about day time savings or any of that. All kinds of software keep time diffs. I am trying to use it in an obvious human readable way right in the file names. lbrtchx
[toc] | [prev] | [next] | [standalone]
| From | Greg Wooledge <greg@wooledge.org> |
|---|---|
| Date | 2023-12-25 02:20 +0100 |
| Message-ID | <HOHNn-fVoJ-1@gated-at.bofh.it> |
| In reply to | #265236 |
On Mon, Dec 25, 2023 at 12:24:55AM +0000, Albretch Mueller wrote: > I am trying to use it in an > obvious human readable way right in the file names. With that restriction, "always use UTC" is going to be your best path forward. It should be possible to convert a well-chosen human-readable time/date format in UTC to epoch time, and vice versa. How human-readable a UTC time/date string actually is will depend on the human, of course. But every other choice is going to be more difficult, or more error-prone, or both.
[toc] | [prev] | [next] | [standalone]
| From | "Andrew M.A. Cater" <amacater@einval.com> |
|---|---|
| Date | 2023-12-25 11:40 +0100 |
| Message-ID | <HOQxj-g0Am-9@gated-at.bofh.it> |
| In reply to | #265236 |
On Mon, Dec 25, 2023 at 12:24:55AM +0000, Albretch Mueller wrote: > On 12/25/23, David Wright <deblis@lionunicorn.co.uk> wrote: > > On Sun 24 Dec 2023 at 23:05:53 (+0000), Albretch Mueller wrote: > >> On 12/18/23, Max Nikulin <manikulin@gmail.com> wrote: > ... > >> Why would %S be in the range > >> second (00..60), instead of (00..59)?: > > > > Leap secondsāsee the example already in the thread: > > https://lists.debian.org/debian-user/2023/12/msg00976.html > > So, a possible (the only?) solution to those kinds of problems would > be to always and explicitly use UTC, right? Or, using the longitude 20 > West (just crossing Iceland, which is 60+ North) or 170 West (too > close to "Vladimir Putin") where so few people live that I don't think > that anyone would care about day time savings or any of that. > Yes - that's the obvious way. I set my machines to /etc/UTC (or /etc/GMT) and leave them there. No daylight saving time, no offsets - all logs unambiguous. That's why (worldwide) radio logkeeping is/was in UTC. If you're travelling in an aircraft, you don't _need_ to know ground time but you do need to know flight time against a reference time. The Royal Air Force keep to UTC wherever they are in the world for just this reason. Anything else is an offset against the reference: if all your Linux boxes have timestamps against the epoch - which can also be related to a human time if you *have* to - you have a reference there.. The problem comes when someone gives you logs that are taken against a different reference. (See also mapping against Greenwhich meridian (UK) and Paris meridian (France) for many years - two sets of maps that aren't *hugely* different on a world scale but locally very different). > All kinds of software keep time diffs. I am trying to use it in an > obvious human readable way right in the file names. > > lbrtchx >
[toc] | [prev] | [next] | [standalone]
| From | Tixy <tixy@yxit.co.uk> |
|---|---|
| Date | 2023-12-25 09:10 +0100 |
| Message-ID | <HOOc9-fZhW-1@gated-at.bofh.it> |
| In reply to | #265234 |
On Sun, 2023-12-24 at 23:05 +0000, Albretch Mueller wrote: [...] > Why would %S be in the range second (00..60), instead of (00..59)?: To support leap seconds [1]. [1] https://en.wikipedia.org/wiki/Leap_second -- Tixy
[toc] | [prev] | [next] | [standalone]
Page 8 of 9 — ← Prev page 1 2 3 4 5 6 7 [8] 9 Next page →
Back to top | Article view | linux.debian.user
csiph-web