[SERVER-3684] In Cygwin, pressing ^C can terminate a mongod running in the background Created: 24/Aug/11  Updated: 15/Aug/12  Resolved: 03/Jun/12

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

Type: Bug Priority: Major - P3
Reporter: Chris Westin Assignee: Tad Marshall
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

using mongo shell from cygwin on windows


Issue Links:
Duplicate
duplicates SERVER-4423 Using MongoDB in the Cygwin shell Closed
Operating System: Windows
Participants:

 Description   

I was using the digg data set from the training course. I was following along with the training course, and got to the sample that says you can query by type.

Here's the console output:
./mongo
MongoDB shell version: 2.0.0-rc0-pre-
connecting to: test
> use digg
switched to db digg
> db.stories.find({"href":{$type});
...

Wed Aug 24 15:33:25 Socket say send() errno:0 The operation completed successful
ly. 127.0.0.1:27017
> db.stories.find({"href":{$type:2}});
Wed Aug 24 15:33:51 trying reconnect to 127.0.0.1
Wed Aug 24 15:33:52 reconnect 127.0.0.1 failed couldn't connect to server 127.0.
0.1
Error: error doing query: unknown
>

After I made the typo, note the missing 2nd closing brace after $type. I got the "..." from the shell. Then I hit ^C. Nothing happened, so I hit return. Then I got the following "operation successful." Then I tried the query again, without the typo, but the server was gone.

I repeated this to make sure, and the same thing happened again.



 Comments   
Comment by Tad Marshall [ 03/Jun/12 ]

Another case of not working very well in Cygwin.

Comment by Chris Westin [ 06/Dec/11 ]

I run mongod in the background by using an ampersand – standard unix shell thing:
$ ./mongod --config ../sandbox/mongodb.conf &

Then I start the shell:
$ ./mongo
>

Comment by Tad Marshall [ 06/Dec/11 ]

So, you are running both mongod.exe and mongo.exe in Cygwin windows (separate, I assume, I don't know how else to do it) and somehow a ^C in one window hits both processes? We need to know what version and bitness of Windows you are running and the versions of the relevant Cygwin components. I saw something on the web when I was Googling for information about Cygwin and consoles that they have changed the behavior since Windows 7 came out, maybe more than once. Something about creating a hidden console, or something like that. If they are sharing a single console among multiple Cygwin shell windows, that might be the thing that makes this possible. So, probably version of Windows, bash and cygwin1.dll, maybe other bits if you can see what is loaded in the processes (using Sysinternals' Process Explorer, for example). Thanks for retesting!

Oh wait, I reread what you wrote ... so you're forking mongod and then running mongo in the same shell? Can you lay out full steps-to-reproduce so I can dupe it?

Comment by Chris Westin [ 06/Dec/11 ]

OK, I think I understand this now. It's definitely a cygwin bug, and we can just document it.

I reproduced the problem again by typing in exactly what I had above. Here it is again:
$ ./mongo
MongoDB shell version: 2.1.0-pre-
connecting to: test
> use digg
switched to db digg
> db.stories.find({"href":{$type});
... [1]+ Exit 12 ./mongod --config ../sandbox/mongodb.conf

cwestin@tellus ~/mongo
$

After the "...", I hit ^C to quit the shell. Then, as you can see, mongod exited. When I first submitted this, I hadn't bothered to check the log, assuming it crashed. As per Eliot's request above, I checked it this time, and found this:

Mon Dec 05 17:13:38 [initandlisten] connection accepted from 127.0.0.1:5910 #4 (1 connection now open)
Mon Dec 05 17:14:11 Ctrl-C signal
Mon Dec 05 17:14:11 got kill or ctrl-c signal, will terminate after current cmd ends
Mon Dec 05 17:14:11 [ctrlCTerminate] now exiting
Mon Dec 05 17:14:11 dbexit:
Mon Dec 05 17:14:11 [ctrlCTerminate] shutdown: going to close listening sockets...
Mon Dec 05 17:14:11 [ctrlCTerminate] closing listening socket: 480
Mon Dec 05 17:14:11 [ctrlCTerminate] closing listening socket: 488
Mon Dec 05 17:14:11 [ctrlCTerminate] shutdown: going to flush diaglog...
Mon Dec 05 17:14:11 [ctrlCTerminate] shutdown: going to close sockets...
Mon Dec 05 17:14:11 [ctrlCTerminate] shutdown: waiting for fs preallocator...
Mon Dec 05 17:14:11 [ctrlCTerminate] shutdown: lock for final commit...
Mon Dec 05 17:14:11 [ctrlCTerminate] shutdown: final commit...
Mon Dec 05 17:14:11 [ctrlCTerminate] shutdown: closing all files...
7/23 30%
Mon Dec 05 17:14:13 [ctrlCTerminate] closeAllFiles() finished
Mon Dec 05 17:14:13 [ctrlCTerminate] journalCleanup...
Mon Dec 05 17:14:13 [ctrlCTerminate] removeJournalFiles
Mon Dec 05 17:14:13 [ctrlCTerminate] shutdown: removing fs lock...
Mon Dec 05 17:14:13 dbexit: really exiting now

This is the normal shutdown sequence. So it didn't crash. It also got the ^C. I'd forgotten that I've seen this before. When I teach the dba training class, one of the exercises is to set up a replica set. The first time I did this, in order to demo failover, I tried to kill one of the mongod processes by bringing it to the foreground (with bg %) and then using ^C to kill it. When I did this, all of my mongod processes exited. As far as I can tell, the cygwin bash shell delivers the ^C signal to all of its children. So that's what must have happened here. (Now when I do the demo in training, I have to run one mongod per cygwin shell).

So our stuff seems to work, but Cygwin seems to have this misbehavior (i.e., delivering SIGINT to all children). I would just document that, as well as recommending against running under Cygwin for production (although it is certainly convenient for development and demos, and given that, I would prefer if we didn't just fail it outright as suggested above).

Comment by Tad Marshall [ 01/Dec/11 ]

I think the key item in this bug report is the "environment" – using mongo shell from cygwin on windows .

We don't work correctly under cygwin. Our Windows code uses the Windows "console" features, and cygwin does not provide a console. If working correctly under cygwin is something that we want to do, then we will need to write new code to handle this. The new code would be a hybrid of the Linux and Windows code. We could easily detect that we are running under cygwin – it sets the environment variable TERM to "cygwin". I'm not sure that this is worth doing, but if we want to do it we could. Another option would be to refuse to run in this mode (TERM=cygwin) or just display an error message and then limp along.

Comment by Eliot Horowitz (Inactive) [ 29/Aug/11 ]

Can't reproduce - can you send server log?

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