Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 240123 - RT: limits.conf realtime entries
RT: limits.conf realtime entries
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: pam (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Tomas Mraz
Depends On: 232700
Blocks: 230752
  Show dependency treegraph
Reported: 2007-05-15 08:10 EDT by Tim Burke
Modified: 2007-11-30 17:07 EST (History)
0 users

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

Attachments (Terms of Use)

  None (edit)
Comment 3 RHEL Product and Program Management 2007-05-15 08:23:53 EDT
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 17:09:59 EDT
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 08:09:42 EDT
> 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 11:27:36 EDT
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 14:31:18 EDT
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.