[SERVER-45342] Send an abort signal instead of a kill signal when archiving Created: 02/Jan/20  Updated: 29/Oct/23  Resolved: 09/Jan/20

Status: Closed
Project: Core Server
Component/s: Testing Infrastructure
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: Raiden Worley (Inactive) Assignee: Raiden Worley (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Problem/Incident
Backwards Compatibility: Fully Compatible
Sprint: STM 2020-01-09
Participants:
Linked BF Score: 50

 Description   

Turns out we can instigate a core dump safely enough by sending an abort signal instead of a kill signal, and the difference in behavior is likely to still allow for valid data files, since the signal handler is a different thread that doesn't take locks. So now we should send an abort signal instead of a kill.



 Comments   
Comment by Githook User [ 09/Jan/20 ]

Author:

{'name': 'Carl Worley', 'email': 'carl.worley@mongodb.com'}

Message: SERVER-45342 Send an abort signal instead of a kill signal when archiving
Branch: master
https://github.com/mongodb/mongo/commit/041ca73b9bd94d3317da8b3cb20ec7691f5c4530

Comment by Raiden Worley (Inactive) [ 03/Jan/20 ]

acm Some test failures can benefit from having core dumps to examine alongside the on-disk data files. The easiest way to force a core dump when a test fails is to send SIGABRT. This ticket will cause resmoke to send SIGABRT to fixtures when a test fails in order to force a core dump. If the fixture had already crashed with a SIGABRT then the dynamically-generated test that sends the signal to the fixture will fail because the fixture isn't already running, so users will still be able to tell if the SIGABRT is "natural" or sent by resmoke.

Comment by Andrew Morrow (Inactive) [ 03/Jan/20 ]

Can I have some more background on what problem is being solved here? Generally, SIGABRT is what is raised when the abort call is invoked, and that is an important part of our error handling internals. It is useful to be able to know that when a process terminates via SIGABRT, that it indicates that the process terminated itself, rather than an external actor having signaled the process to terminate it.

Generated at Thu Feb 08 05:08:32 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.