[SERVER-1832] 'repair' option to control script in packaged build Created: 22/Sep/10  Updated: 19/May/14  Resolved: 25/Jan/11

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

Type: Improvement Priority: Major - P3
Reporter: Roger Binns Assignee: Richard Kreuter (Inactive)
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Ubuntu 10.04


Participants:

 Description   

Short story - add a 'repair' option the main control script (the one you can invoke with 'start', 'stop', 'restart' etc options.) To do a repair I should be able to do:

sudo service mongodb repair

Justification: currently if you use the packaged build then doing a repair is a pain.

First of all you don't even know it is needed. I killed the server with -9 to demonstrate this:

$ ps -ef | grep mongodb
rogerb 14098 2352 0 15:24 pts/0 00:00:00 grep mongodb
$ sudo service mongodb start
mongodb start/running, process 14105
$ ps -ef | grep mongodb
rogerb 14110 2352 0 15:24 pts/0 00:00:00 grep mongodb

As you can see the server is not running, start claims it is, but it isn't. On checking the logs you find the message about the lockfile.

To actually do the repair requires two things. Firstly you have to figure out where the lock file is and delete it. For packaged builds this information is known. See also SERVER-1609.

Secondly you have to run repair with the right user and data directories. config files etc. All this is annoying to string together and the packaged build already knows all those values.



 Comments   
Comment by Roger Binns [ 26/Jan/11 ]

Just to clarify you have conflated two separate issues. One is running repair automatically which is a different ticket SERVER-1386.

This issue is purely that if I know I want to run repair on a packaged build I want to be able to do so reliably. It is difficult to work out what the command line is manually since it requires knowledge of what userid mongodb was running under, location of the various config files, how to check if it is running etc. Those decisions were made by the rest of the MongoDB packaging, not me. I don't have to know or care what they are to start or stop the server.

All I want is a single command that when run uses the packaged configuration to do the repair. Having /etc/init.d/mongodb be that entry point is the nicest but a separate script is just.

As a challenge right now, I am a regular user with sudo privileges and need to do a repair on a database that has not started. Exactly which user should I switch to and what combination of sudo/su commands will do that, where is the mongod binary, is it -repair or --repair, what are the pathnames of the config files I must pass? The packaging knows the answer to all of those!

Comment by Richard Kreuter (Inactive) [ 25/Jan/11 ]

(Additionally, we try to follow MySQL packaging to a degree, and it seems that the analogous myisamcheck does not get run in their init scripts.)

Comment by Richard Kreuter (Inactive) [ 25/Jan/11 ]

Closing this as a wontfix because:

(a) the need for repair goes away in 1.8 with single-server durability,
(b) repair isn't totally safe, and so isn't a good idea to run automatically,
(c) mongod is started via upstart on sufficiently recent Ubuntu versions, and upstart won't let you add new arguments (as far as I can tell)

Generated at Thu Feb 08 02:58:11 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.