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
release.

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.

> 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.

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.

or

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.

It will be better to include this file (/etc/security/limits.d/realtime.conf) in
RHEL-RT.