[SERVER-50282] Provide a debugging setup script for spawnhosts that load artifacts with coredumps Created: 19/May/20 Updated: 29/Oct/23 Resolved: 20/Aug/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Testing Infrastructure |
| Affects Version/s: | None |
| Fix Version/s: | 4.7.0 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Daniel Gottlieb (Inactive) | Assignee: | Daniel Gottlieb (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | cli | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Sprint: | Sharding 2020-08-24 | ||||||||||||
| Participants: | |||||||||||||
| Linked BF Score: | 6 | ||||||||||||
| Story Points: | 0 | ||||||||||||
| Description |
|
Overlong filenames truncating important properties is actually a bug. This ticket has been repurposed to provide a script that unpackages files necessary for inspecting a coredump on a spawnhost. It assumes the bug will be eventually fixed (and the bug only impacts a subset of cases). Original Description Unfortunately when filenames are long, important properties can be trimmed such as the keyword coredump[1]. What makes this difficult is that it not only breaks my script (acceptable, this sort of scripting isn't supported or built on some established agreement), but it also breaks my ability to do the corollary work by hand. Doing a tar -tf <archive> AFAIK is a complete filescan. At that point it's faster to just download the coredumps by hand. This arguably defeats the purpose of spawning a host with artifacts loaded. I don't know what a feasible solution here is. There's probably a reason why filenames are long (for uniqueness? though IMO, unreadable). Some ideas:
[1]
|
| Comments |
| Comment by Githook User [ 20/Aug/20 ] |
|
Author: {'name': 'Daniel Gottlieb', 'email': 'daniel.gottlieb@mongodb.com', 'username': 'dgottlieb'}Message: |
| Comment by Daniel Gottlieb (Inactive) [ 12/Aug/20 ] |
|
I've moved this into a server ticket. As part of my investigation, I found the original problem of trimming the beginning of filenames was actually a bug. Given that, I was able to focus this ticket into just providing a script that can set up a spawnhost experience for loading gdb against a coredump. I was able to achieve that with a patch that only touches the server repository. That said, the usability/discoverability of the patch could be improved, likely requiring help from evergreen, but that can be discussed and ticketed out separately. |
| Comment by Brooke Miller [ 06/Aug/20 ] |
|
We are timeboxing this investigation for Dan to 5 days. |
| Comment by Daniel Gottlieb (Inactive) [ 06/Aug/20 ] |
|
I'm going to take this ticket for the next sprint to investigate a different angle where this can be tackled more on the mongodb side. If the investigation proves fruitful, I'll move this ticket into the SERVER project. There might still be some asks from Evergreen (to be filed separately), but I expect they'd be server agnostic. |
| Comment by Chaya Malik [ 09/Jul/20 ] |
|
Since the file names are defined in the s3_put command in the project YAML and it's not Evergreen generating the file name, it is hard to shorten it in a meaningful way. We can attempt to shorten it on fetch, but it would be hard for us to parse out the unimportant parts in a generic way. Adding environment variables containing absolute paths such as COREDUMP_ARCHIVE would mean adding task-specific information in the Evergreen code base, as opposed to keeping Evergreen general. It seems like there is no ideal solution to this problem. |