[SERVER-32915] Set CAP_IPC_LOCK capability in Linux packages Created: 25/Jan/18  Updated: 05/Dec/22  Resolved: 16/Nov/22

Status: Closed
Project: Core Server
Component/s: Packaging
Affects Version/s: None
Fix Version/s: 4.1 Desired

Type: Improvement Priority: Major - P3
Reporter: Spencer Jackson Assignee: [DO NOT ASSIGN] Backlog - Server Development Platform Team (SDP) (Inactive)
Resolution: Won't Do Votes: 0
Labels: sdp-backlog-purge
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVER-32773 mlock: Operation not permitted Closed
Assigned Teams:
Server Development Platform
Participants:

 Description   

MongoDB mlocks some memory for authentication and the encrypted storage engine. The amount it can lock is dependent on a ulimit. However, this only applies to 'unprivileged' processes. A process with the CAP_IPC_LOCK capability flag set on its binary can mlock an unlimited amount of memory, regardless of the environment it was executed in. This seems to be what we want MongoDB to be able to do: use as much mlocked memory as is required.

To make this work, we should add CAP_IPC_LOCK to mongo, mongod, and mongos in our RPM and deb installers. RPM seems to have a macro called %caps for setting capabilities. deb probably has something similar.



 Comments   
Comment by Iryna Zhuravlova [ 16/Nov/22 ]

After a careful backlog refinement, the team decided to close this ticket because of its low priority and limited resource capacity. If you believe that this ticket requires additional attention from the team and should be re-opened, feel free to change the status to "Needs Scheduling" and ping me or alexander.neben@mongodb.com 

Comment by Gregory McKeon (Inactive) [ 29/Jan/18 ]

Sending to build team since it's part of packaging, feel free to reach out to spencer.jackson with questions.

Comment by Spencer Jackson [ 25/Jan/18 ]

The existence of this capability came up in SERVER-32773, it might be useful in our regular packages.

Generated at Thu Feb 08 04:31:42 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.