Bug 240123 - RT: limits.conf realtime entries
Summary: RT: limits.conf realtime entries
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: pam (Show other bugs)
(Show other bugs)
Version: 5.0
Hardware: All Linux
Target Milestone: ---
: ---
Assignee: Tomas Mraz
QA Contact:
Depends On: 232700
Blocks: 230752
TreeView+ depends on / blocked
Reported: 2007-05-15 12:10 UTC by Tim Burke
Modified: 2007-11-30 22:07 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-07-23 18:31:18 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Comment 3 RHEL Product and Program Management 2007-05-15 12:23:53 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update

Comment 4 Tim Burke 2007-05-22 21:09:59 UTC
Adding some info from bug #228604

First, a correction to the limits.conf mods listed above:

@realtime       soft    cpu             unlimited
@realtime       -       rtprio          100
@realtime       -       nice            40
@realtime       -       memlock         unlimited

These settings are not really application specific, any real-time application
will require the ability to set scheduling policies and priorities.  Memlock is
also commonly used to prevent paging latencies.  It makes sense, IMO, for a
real-time OS such as RHEL5-RT to include the above config changes by default and
include the realtime group, since the purpose of the OS will be to run real-time
applications.  Otherwise, every real-time app will be adding identical (or very
similar) configs to limits.conf, which is an undue burden on the app developers
and complicates maintenance of the config file.

Comment 7 Tim Burke 2007-07-09 12:09:42 UTC
> Now, the next question is.... I'm not sure how this was implemented and 
> > what steps the user must do to take advantage of the capability.  Could 
> > you please refer to some usage information?

It should be simply enough to create group realtime and assign the users
(which should get these real time limits set to the values specified in
the bug report) to the group.

Comment 8 Tomas Mraz 2007-07-20 15:27:36 UTC
Reopening - this causes regression on systems where the group realtime doesn't
exist and which are setup to use remote server for user info (LDAP, etc.).

Possible solutions 
1) do not include this realtime.conf settings in RHEL5.1, put it only in RHEL RT
where the group is properly created.


2) add bug against setup package to include the realtime group in RHEL5.1. But
this will not work probably because it'd just create a .rpmnew file on upgrades.

Comment 11 Tomas Mraz 2007-07-23 18:31:18 UTC
It will be better to include this file (/etc/security/limits.d/realtime.conf) in

Note You need to log in before you can comment on or make changes to this bug.