[SERVER-1141] mongod could exit whenit cannot bind listen port Created: 23/May/10 Updated: 12/Jul/16 Resolved: 03/Jun/10 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Usability |
| Affects Version/s: | 1.4.0, 1.4.2, 1.5.1 |
| Fix Version/s: | 1.5.3 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | dan | Assignee: | Mathias Stearn |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
at least OS X 64 bit, linux 32 bit - probably all |
||
| Backwards Compatibility: | Minor Change |
| Participants: |
| Description |
|
At the moment, if you start mongod and it cannot acquire a lock on the data dir (given by the --dbpath option) then it will exit. On the other hand, if you specify a port with --port and it cannot bind to that port the process hangs indefinitely. Consistency between these two seems like it would be desirable. in particular, I would like it if the server exited upon failure to acquire a port, since starting up a mongod process for a particular batch of unit tests is desirable - in the case that you fail to acquire your desired port, you wish to know this fact before your tests start overwriting data that you may wish to keep around, and you wish to know that this has happened by the fact that the server process has exited, rather than having to parse its STDOUT. a trivial demonstration of this problem: run the two processes with the conflicting port will still be running, but not the conflicting db path. tested this behaviour with 1.4.0 (OSX 64 bit), 1.5.1 and today's nightly (linux 32 bit) |
| Comments |
| Comment by auto [ 03/Jun/10 ] |
|
Author: {'login': 'RedBeard0531', 'name': 'Mathias Stearn', 'email': 'mathias@10gen.com'}Message: Exit if can't bind to port |
| Comment by Mathias Stearn [ 03/Jun/10 ] |
|
Fixed typo in description |
| Comment by dan [ 23/May/10 ] |
|
oops! for > the two processes with the conflicting port will still be running, but not the conflicting db port. read > the two processes with the conflicting port will still be running, but not the conflicting db path. Sorry! |