[SERVER-32103] CTRL-C in mongo shell does not terminate long running ops if connected to mongos Created: 28/Nov/17 Updated: 06/Dec/22 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Shell |
| Affects Version/s: | 3.4.10 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | James Kovacs | Assignee: | Backlog - Query Execution |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | neweng, query-44-grooming | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||
| Assigned Teams: |
Query Execution
|
||||||||||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||||||||||
| Steps To Reproduce: |
If you repeat the above steps connected to the mongod directly instead, you are prompted to terminate the long-running command as expected. |
||||||||||||||||||||||||||||
| Sprint: | Query 2018-03-26 | ||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||
| Case: | (copied to CRM) | ||||||||||||||||||||||||||||
| Description |
|
killOperationsOnAllConnections is called in response to CTRL-C in the mongo shell. It finds long-running operations started by this shell and provides the user the option to terminate them. This is accomplished with the currentOp and killOp commands. For each connection, the shell calls currentOp and examines client or client_s to determine if that command was started by the current shell. When a command is run against a mongod, client contains the IP:PORT of the mongo shell. These commands prompt for termination. If however the command is routed through a mongos, client_s contains the IP:PORT of the mongos, not the mongo shell. These commands do not prompt for termination and are left running on the mongod. |
| Comments |
| Comment by David Storch [ 28/Jun/19 ] |
|
Flagging for re-triage. We may be able to pursue a simpler fix to this now. ian.boros's prototype for a fix involved creating a new DBCommandCursor concept, but this may now be supported by the pre-existing DBClientCursor class. |
| Comment by Charlie Swanson [ 08/Feb/18 ] |
|
Ok - so I think I've figured out what's going on here. It looks like the shell is trying to identify which operations in the currentOp output were started by itself (this particular instance of the shell). It wants to do this to avoid killing all operations on the server, instead killing only its own. To do this, it's looking at either the 'client' or 'client_s' field in the currentOp output. The 'client' field usually identifies who started the operation (it's something like "127.0.0.1:53518", from what I can tell this is the host and port that the request came from). When the shell is talking to a mongod, this will be the shell's own URI because the request was sent directly from the shell to the mongod. Thus when connected to a mongod, the shell will be able to correctly kill its own operations. When currentOp is run against mongos, the 'client' field is renamed to be 'client_s', to make it clear that this is describing which mongos the operation originated from. The shell uses this field to try to figure out if the request came from itself, but it will never match. The shell never connects directly to the mongod which generates this information, so the "client_s" field will always be the host and port corresponding to the mongos' request. So, the shell never finds any operations in progress that it started, and never prompts the user to interrupt them. It looks like interrupting operations from a shell connected to a mongos has just never worked (I tested on 3.2, 3.4 and 3.6 - it just crashed on 3.2 ( I see two options going forward:
|
| Comment by Ian Whalen (Inactive) [ 12/Jan/18 ] |
|
Assigning to Charlie for future sprint to at least investigate complexity so we can/should decide whether to work into this project. |
| Comment by Gregory McKeon (Inactive) [ 05/Jan/18 ] |
|
Sending to Query team to see if this can be done as part of the sharded kill epic. |