I tested this, first I installed MongoDB 2.4.6 with brew, and then used launchctl to load and unload. In my testing, it sends a SIGTERM to the mongod process which then shuts down as expected. Here are the commands I used as well as the logs for the mongod
process:
Commands:
launchctl load -w /usr/local/Cellar/mongodb/2.4.6/homebrew.mxcl.mongodb.plist
launchctl unload -w /usr/local/Cellar/mongodb/2.4.6/homebrew.mxcl.mongodb.plist
Logs:
tail -f /usr/local/var/log/mongodb/mongo.log
Tue Oct 22 17:33:32.774 [initandlisten] MongoDB starting : pid=13192 port=27017 dbpath=/usr/local/var/mongodb 64-bit host=adamc-mbp.local
Tue Oct 22 17:33:32.774 [initandlisten] db version v2.4.6
Tue Oct 22 17:33:32.774 [initandlisten] git version: nogitversion
Tue Oct 22 17:33:32.774 [initandlisten] build info: Darwin minimountain.local 12.4.0 Darwin Kernel Version 12.4.0: Wed May 1 17:57:12 PDT 2013; root:xnu-2050.24.15~1/RELEASE_X86_64 x86_64 BOOST_LIB_VERSION=1_49
Tue Oct 22 17:33:32.774 [initandlisten] allocator: tcmalloc
Tue Oct 22 17:33:32.774 [initandlisten] options: { bind_ip: "127.0.0.1", command: [ "run" ], config: "/usr/local/etc/mongod.conf", dbpath: "/usr/local/var/mongodb", logappend: "true", logpath: "/usr/local/var/log/mongodb/mongo.log" }
Tue Oct 22 17:33:32.775 [initandlisten] journal dir=/usr/local/var/mongodb/journal
Tue Oct 22 17:33:32.775 [initandlisten] recover : no journal files present, no recovery needed
Tue Oct 22 17:33:32.806 [websvr] admin web console waiting for connections on port 28017
Tue Oct 22 17:33:32.806 [initandlisten] waiting for connections on port 27017
Tue Oct 22 17:34:21.682 [signalProcessingThread] got signal 15 (Terminated: 15), will terminate after current cmd ends
Tue Oct 22 17:34:21.682 [signalProcessingThread] now exiting
Tue Oct 22 17:34:21.682 dbexit:
Tue Oct 22 17:34:21.682 [signalProcessingThread] shutdown: going to close listening sockets...
Tue Oct 22 17:34:21.682 [signalProcessingThread] closing listening socket: 9
Tue Oct 22 17:34:21.682 [signalProcessingThread] closing listening socket: 10
Tue Oct 22 17:34:21.682 [signalProcessingThread] closing listening socket: 11
Tue Oct 22 17:34:21.682 [signalProcessingThread] removing socket file: /tmp/mongodb-27017.sock
Tue Oct 22 17:34:21.682 [signalProcessingThread] shutdown: going to flush diaglog...
Tue Oct 22 17:34:21.682 [signalProcessingThread] shutdown: going to close sockets...
Tue Oct 22 17:34:21.682 [signalProcessingThread] shutdown: waiting for fs preallocator...
Tue Oct 22 17:34:21.682 [signalProcessingThread] shutdown: lock for final commit...
Tue Oct 22 17:34:21.683 [signalProcessingThread] shutdown: final commit...
Tue Oct 22 17:34:21.692 [signalProcessingThread] shutdown: closing all files...
Tue Oct 22 17:34:21.692 [signalProcessingThread] closeAllFiles() finished
Tue Oct 22 17:34:21.692 [signalProcessingThread] journalCleanup...
Tue Oct 22 17:34:21.692 [signalProcessingThread] removeJournalFiles
Tue Oct 22 17:34:21.692 [signalProcessingThread] shutdown: removing fs lock...
Tue Oct 22 17:34:21.693 dbexit: really exiting now
I did this several times to confirm the behavior. In Chrome at least the status page no longer responds and I receive an error (as expected) once it has been shut down.
The only difference between what I am doing and what you have posted is that I am not using sudo
(in fact it refuses to load or unload due to dubious ownership of the file). So, I changed the ownership of the plist file to root and tried sudo
with the same results.
The only way I was able to recreate a failure to unload was as follows:
- Start with
sudo launchctl
(root is the owner of the plist file)
- Change ownership of the plist file back to my regular user
- Try to unload without
sudo
This fails with an error however:
launchctl: Error unloading: homebrew.mxcl.mongodb
Note: Subsequently changing the ownership back to the regular user made the unload successful
Similarly, this also produces the same error:
- Start without
sudo
(regular user owns the plist file)
- Change ownership of the plist file to root
- Try to unload with sudo
I was unable to recreate the silent failure you seem to be having with any of the various combinations I tried.
Some information gathering tips which may give you a clue:
- When you launch with launchctl, what does the output of this command say:
launchctl list | grep mongodb
? (it should list something like 13340 - homebrew.mxcl.mongodb
- If you run this same command after you run unload (without error), it should show the exit status in that middle column (-15)
- Sometimes it can take a while for MongoDB to exit - so tail the log (see example above), see if the TERM signal is being received
- Why is it you are using sudo? Have you installed brew as root? If so this might be at the core of the issue here - generally it is not recommended to run MongoDB as root.
Best Answer
As per MongoDB documentation here Collection-level access control allows administrators to grant users privileges that are scoped to specific collections.
Administrators can implement
collection-level
access control through user-defined roles. By creating a role with privileges that are scoped to a specific collection in a particular database, administrators can provision users with roles that grant privileges on a collection level.Required Access
To create a role in a database, you must have:
Built-in
rolesuserAdmin
anduserAdminAnyDatabase
providecreateRole
andgrantRole
actions on their respective resources.To create a role with
authenticationRestrictions
specified, you must have thesetAuthenticationRestriction
action on the database resource which the role is created.Roles
In the roles field, you can specify both built-in roles and user-defined roles.
For your further ref here , here and here