Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Sat, 25 Sep 2021 11:35:49 -0700
From:   Rustam Kovhaev <rkovhaev@gmail.com>
To:     Al Viro <viro@zeniv.linux.org.uk>
Cc:     linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
        binutils@sourceware.org, gdb-patches@sourceware.org
Subject: Re: [RFC][PATCH] coredump: save timestamp in ELF core
Message-ID: <YU9sBdyMrUsLk0XC@nuc10>
References: <20210925171507.1081788-1-rkovhaev@gmail.com>
 <YU9kSgEmojalPybp@zeniv-ca.linux.org.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <YU9kSgEmojalPybp@zeniv-ca.linux.org.uk>
Precedence: bulk

On Sat, Sep 25, 2021 at 06:02:50PM +0000, Al Viro wrote:
> On Sat, Sep 25, 2021 at 10:15:07AM -0700, Rustam Kovhaev wrote:
> > Hello Alexander and linux-fsdevel@,
> > 
> > I would like to propose saving a new note with timestamp in core file.
> > I do not know whether this is a good idea or not, and I would appreciate
> > your feedback.
> > 
> > Sometimes (unfortunately) I have to review windows user-space cores in
> > windbg, and there is one feature I would like to have in gdb.
> > In windbg there is a .time command that prints timestamp when core was
> > taken.
> > 
> > This might sound like a fixed problem, kernel's core_pattern can have
> > %t, and there are user-space daemons that write timestamp in the
> > report/journal file (apport/systemd-coredump), and sometimes it is
> > possible to correctly guess timestamp from btime/mtime file attribute,
> > and all of the above does indeed solve the problem most of the time.
> > 
> > But quite often, especially while researching hangs and not crashes,
> > when dump is written by gdb/gcore, I get only core.PID file and some
> > application log for research and there is no way to figure out when
> > exactly the core was taken.
> > 
> > I have posted a RFC patch to gdb-patches too [1] and I am copying
> > gdb-patches@ and binutils@ on this RFC.
> > Thank you!
> 
> IDGI.  What's wrong with the usual way of finding the creation date of any
> given file, including the coredump one?

Sometimes file attributes get reset/modified when the file changes hands.
Here is what usually happens: 
We ask customer to take a few cores of some hanging process, customer
does so, then copies the files out from his Linux servers/machines, then
creates an archive on his machine (usually windows/mac) and then, emails
or uploads the archive, and, if we are lucky we get correct creation
date of the core in the archive, but most of the time creation date gets
reset/modified somewhere along this process.