Add initial version of the debug info gathering script

[jacekn]

What

Add initial version of the debug info gathering script

Why

We want to make it easier to gather information useful for troubleshooting

[SirTyson]

Thanks for putting this together! I think it mostly looks like we have everything we need, but there are a few extra pieces that could be useful:

1. Optionally specify a core executable path. This isn't super important because all the production use cases that we're targeting should just be using stellar-core, but during development we often use one of builds that specify a specific path, and this script could be useful.
2. Zip DB when using a SQLite backend. I don't think this is possible with Postgres, but I think (and could be wrong) that it's relatively easy to do in SQLite. We're in the process of getting rid of Postgres support anyway, so if you can parse the SQLite DB image path from the config and include it in the final zip result, it would be useful.
3. Attempt to parse log path from the config file. I'm not sure what log systems other folks use, but during testing runs I just use a single file as my running log. If most everyone is encoding time info into their logs then you can skip this, I might be the odd one out here. This isn't super important so feel free to skip it in the interest of time, it might be a little tricky to detect when the config specifies a deterministic log name vs. a date based one.

[jacekn]

Thanks for putting this together! I think it mostly looks like we have everything we need, but there are a few extra pieces that could be useful:

1. Optionally specify a core executable path. This isn't super important because all the production use cases that we're targeting should just be using `stellar-core`, but during development we often use one of builds that specify a specific path, and this script could be useful.

Done

2. Zip DB when using a SQLite backend. I don't think this is possible with Postgres, but I think (and could be wrong) that it's relatively easy to do in SQLite. We're in the process of getting rid of Postgres support anyway, so if you can parse the SQLite DB image path from the config and include it in the final zip result, it would be useful.

Done

3. Attempt to parse log path from the config file. I'm not sure what log systems other folks use, but during testing runs I just use a single file as my running log. If most everyone is encoding time info into their logs then you can skip this, I might be the odd one out here. This isn't super important so feel free to skip it in the interest of time, it might be a little tricky to detect when the config specifies a deterministic log name vs. a date based one.

Done. Logs with date in the filename are a bit tricky but for this reason the script tries to get last 24h worth of files with .log suffix. So with this this in place I believe we'll be fine.

[anupsdf]

Looks like the cargo-deny CI check is failing because of a new security advisory https://rustsec.org/advisories/RUSTSEC-2024-0344
We might explore putting this advisory in the ignore list since we cannot switch to curve25519-dalek 4.1.3 prior to protocol 22.

[SirTyson]

Seems like it's working great, thanks for working on this!

[jacekn]

@anupsdf @SirTyson merge is blocked on the cargo-deny check which is unrelated to this change.
Can I leave it up to you to address the problem with the check?

[SirTyson]

We're currently changing our Github CI so we can't merge anything at the moment, but should have it resolved in a day or two.

[SirTyson]

CI is back online. If you rebase this off master, the last CI check should be resolved then I can merge

[jacekn]

@SirTyson all checks pass now so if it looks good from our side can you merge?