From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) by sourceware.org (Postfix) with ESMTPS id 4ADF93858034; Mon, 24 May 2021 10:17:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 4ADF93858034 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=debian.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=luca.boccassi@gmail.com Received: by mail-wr1-f42.google.com with SMTP id x8so27936975wrq.9; Mon, 24 May 2021 03:17:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:user-agent:mime-version; bh=C55TbtqoqHUGC64Btfm6UN7hQDnTlXyiV/mqpB4NIDE=; b=EscXdUpbO4QHn4LDbjfHBRbsNvaUKdTy/qsg5bf8kNc5gzi3nxO+/sFaGMNcU73cnr TRKS2fKaR2z+KBQtr/rE8sTuK9/NYG0wjQyAAR5FZBwarvdlEqZWMJl/GX1Z7KCdLg/+ dnY5K5wnW/anxOAcYmxTi4GO8v4KPSTezCAkEI+yWV0nJvUdcFLZAhJAF6sQCvbSvZUY KXsHwGbp2QZTHLuo5rojlwLjwtA7JjB8hG/++bRCU2ilc/ntYx1A3Ih3YZL4vmjUk59x CPDLRSV3WovUltezXP04CG3znhhkBX2osPtm0fcZjxcKcohQeXfwQ5ZbWy8iiPnXOgHm fwyg== X-Gm-Message-State: AOAM530Nit9r/CXerKx/DzEZgYnoQI6WasmiCTSYi+nQNVQ6odyjdkNF aXKt5H5ugArF4JxHobYKc6Y= X-Google-Smtp-Source: ABdhPJyqmCGIKtCGu0mbk7EmvZQZ2BVeJRI8SjPwAOjMG+w4A+ZESivBiN4wmkNLSvs2VKJBMfIhIA== X-Received: by 2002:a5d:6e03:: with SMTP id h3mr9802214wrz.138.1621851477377; Mon, 24 May 2021 03:17:57 -0700 (PDT) Received: from localhost ([88.98.246.218]) by smtp.gmail.com with ESMTPSA id c194sm7536958wme.46.2021.05.24.03.17.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 24 May 2021 03:17:56 -0700 (PDT) Message-ID: <661b25a4999571e41148beb5d487488f58dc72c0.camel@debian.org> Subject: Re: Storing package metadata in ELF objects From: Luca Boccassi To: Mark Wielaard , Guillem Jover Cc: devel@lists.fedoraproject.org, SystemD Devel , debhelper@packages.debian.org, binutils@sourceware.org, Lennart Poettering , debian-dpkg@lists.debian.org, "elfutils-devel@sourceware.org" , Zbigniew =?UTF-8?Q?J=C4=99drzejewski-Szmek?= Date: Mon, 24 May 2021 11:17:49 +0100 In-Reply-To: References: <2b91ec1654b6c07cca2b5c113df772c85c0dd22c.camel@debian.org> <46a14fa448452ba7c695c7e7eeb4ef9348f5475b.camel@debian.org> Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-Mi4TC1FksEVqzazCYeuE" User-Agent: Evolution 3.30.5-1.2 MIME-Version: 1.0 X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00, FREEMAIL_FORGED_FROMDOMAIN, FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: elfutils-devel@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Elfutils-devel mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 May 2021 10:18:00 -0000 --=-Mi4TC1FksEVqzazCYeuE Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, 2021-05-19 at 16:58 +0200, Mark Wielaard wrote: > Hi Guillem, >=20 > On Wed, 2021-05-19 at 02:19 +0200, Guillem Jover wrote: > > So this is where I guess I'm missing something. To be able to make > > sense of the coredumps there are two things that might end up being > > relevant, backtraces and source code. systemd-coredump might already > > emit a backtrace, and depending on the information provided it might > > be more or less useful. If one needs the actual debug symbols there's > > already some external querying/fetching required, and if distribution > > specific source code is required because many distributions patch > > upstream source, then even more querying/fetching will be required. > >=20 > > Which is why I'm not seeing why this standalone and isolated metadata > > would be of much help by itself. As in, the way I see it, either the > > information from systemd (w/o the extra metadata) is sufficient to > > track down bugs, or that querying/fetching would be needed anyway, at > > which point the metadata can be inferred too then? >=20 > Because without that metadata you cannot easily figure out where/how to > get the files needed to properly track down the bugs. But using that > metadata you can figure out where the debuginfod server is that can > provide all that information for the binaries/core files (or a distro > specific method if the distributor doesn't have a debuginfod server > yet). Yes, that is a good use case. Another use case is that the person (or bot) who first looks at the journal with the crash notification and the metadata might not necessarily be the one that does the full in-depth debugging. First level support will look at things and go "oh this is from package X at version Y, therefore team Z needs to chime in". Or it can see that it's version A.B.C, which is listed as known buggy, and ignore the issue. Or a myriad of other combinations. Then there are automated systems, parsing logs and creating tickets. Having the structured metadata available in the journal in the crash message means much more complex and useful querying and ticket creation systems can be set up. You _cannot_ just go and query random remote internet servers from these systems, they need to be network-isolated, as logs can have confidential data from customers. The main point is, there are many many things that happen between a crash and the team owning the component looking up debugging symbols and loading core files. This feature is very very useful for a whole lot of those things. > > Oh, I was thinking about those mixed environments, full chroots or > > stripped down containers, from different vendors, but affecting Debian > > installations. What I'm also probably missing here is how does the > > metadata help for a third-party that is not expected to track/keep/uplo= ad > > debug symbols nor source packages into some repository, because otherwi= se > > I'm not seeing how they'd make use of the cores (if they are insufficie= nt > > by themselves) to debug issues? I guess my question back would be what > > would they do with the metadata if they do not have the debug symbols > > nor the sources readily available? Also assuming of course they exercis= e > > good practices such as never reusing the same package-version-arch tupl= e > > for different builds, and similar. :) >=20 > Different builds will have different build-ids, so they can be kept > apart. But even if without the distributor having added debuginfod > meta-data and providing a server to fetch the extra symbols, debuginfo, > sources, the extra meta-data is useful to administrators. Just seeing > that crashes are associated with specific distro/version/packages helps > narrow down instabilities. Precisely - again this is a very much real use case. In my case, the engineers doing support and looking at the logs (and only at the logs - no access to the running systems is permitted) _want_ this, because it helps them. Being able to know at a glance to the journal exactly what is borken, with version info, is extremely valuable to them. Yes the version info might not be precise for a minority of use cases that override the binary version with something different than the source version, but that's fine as it's far and few, mostly affects metapackages, and even then it can be documented clearly that the reference is to the source version, not the binary one. --=20 Kind regards, Luca Boccassi --=-Mi4TC1FksEVqzazCYeuE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEErCSqx93EIPGOymuRKGv37813JB4FAmCrfU0ACgkQKGv37813 JB4+QxAAhNhZsPpFiFu/bUA4mFvRYKohsnL6QSG/T4p9FkFmpKnR4FayskEKNAN7 zbVZHQvNIl/CdKetDpku4SxxznNB8+TYKOlUKRyFQPanbLPAfM9acoOC2nMKpNz7 uESZNzxw4rpFWZFkxY0xxF3FXTw3ufGVcCukpDbO5B893bQhbAPxmmoAl71sPzaZ nmP0EQL6mpRYUN+VHkEduMw28h861V+SOhH2By/+s8wOOEH4xAdHmGIlFJ4rcC+K KKdd/P+hl35JoenGV8OBgU9TMPOskfZb7J5qh7Xr/5bXwlefurLov48PKGI5LAly kK/dnQ+pI62n45v8oYJOUetfzz4PV7DmLeoEa5UNr+4Yp9+l6Ds4mA2CHlUUGSsv usJQYEHgpuCjbck1Tr93YZO2CDA2GzYTztUdMymbbZGfYBq2l7hIiI0jdGnvhHAg gPLwhAzXaAYdNIdcpA1zCOfe4J8VjCmIJD/ZQy+1KMTp706xbIMNywJE940B6S2S z+4Q6S35ZTTUZU3AwvCaMC2i9+lnTHJJeL+GH5EqJ2c3FwdX613aJg45bms32kd6 6EJT6ZmtCSdEygtVwJe/TFudAifQZwRHfkLPcc2Xks7jb7NhqbI9mH0EolDKpIac 7fIrD419uDVvo8DiXEly4+eu2Dau/ImsIkMI2sZp+Z4Wy1Q4PtQ= =3nst -----END PGP SIGNATURE----- --=-Mi4TC1FksEVqzazCYeuE--