[ Platform Documentation ]

[ Title ]

[ Contents ]

[ Previous ]

[ Next ]

[ Index ]

---

lsb.users

---

The lsb.users file is used to configure user groups, hierarchical fairshare for users and user groups, and job slot limits for users and user groups. It is also used to configure account mappings in a MultiCluster environment.

This file is optional.

The lsb.users file is stored in the directory LSB_CONFDIR/cluster_name/configdir, where LSB_CONFDIR is defined in lsf.conf.

Contents

• UserGroup Section
• User Section
• UserMap Section

[ Top ]

---

UserGroup Section

Optional. Defines user groups.

The name of the user group can be used in other user group and queue definitions, as well as on the command line. Specifying the name of a user group has exactly the same effect as listing the names of all users in the group.

The total number of user groups cannot be more than MAX_GROUPS in lsbatch.h.

Structure

The first line consists of two mandatory keywords, GROUP_NAME and GROUP_MEMBER. The USER_SHARES keyword is optional. Subsequent lines name a group and list its membership and optionally its share assignments.

Each line must contain one entry for each keyword. Use empty parentheses () or a dash - to specify the default value for an entry.

Example of a UserGroup Section

Begin UserGroup
GROUP_NAME   GROUP_MEMBER
groupA       (user1 user2 user3 user4)
groupB       (groupA user5)
groupC       (!)
End UserGroup
Begin UserGroup
GROUP_NAME   GROUP_MEMBER            USER_SHARES
groupB       (user1 user2)           ()
groupC       (user3 user4)           ([User3,3] [User4,4])
groupA       (GroupB GroupC User5)   ([User5,1] [default,10])
End UserGroup

GROUP_NAME

An alphanumeric string representing the user group name. You cannot use the reserved name all or a / in a group name, and group names must not conflict with user names.

GROUP_MEMBER

A list of user names or user group names that belong to the group, enclosed in parentheses and separated by spaces. Group names must not conflict with user names.

User and user group names can appear on multiple lines, because users can belong to multiple groups.

User groups may be defined recursively but must not create a loop.

Syntax

(user_name | user_group ...) | (all) | (!)

Specify the following, all enclosed in parentheses:

• user_name | user_group

  User and user group names, separated by spaces. User names must be valid login names.

  User group names can be LSF user groups defined previously in this section, or UNIX and Windows user groups.

• all

  The reserved name all specifies all users in the cluster.

• !

  The exclamation mark ! specifies that the group membership should be retrieved via egroup.

USER_SHARES

Optional. Enables hierarchical fairshare and defines a share tree for users and user groups.

By default, when resources are assigned collectively to a group, the group members compete for the resources according to FCFS scheduling. You can use hierarchical fairshare to further divide the shares among the group members.

Syntax

([user, number_shares])

Specify the arguments as follows:

• Enclose the list in parentheses, even if you do not specify any user share assignments.
• Enclose each user share assignment in square brackets, as shown.
• Separate the list of share assignments with a space.
• user

  Specify users or user groups. You can assign the shares to:

  • A single user (specify user_name)
  • Users in a group, individually (specify group_name@) or collectively (specify group_name)
  • Users not included in any other share assignment, individually (specify the keyword default) or collectively (specify the keyword others)

  By default, when resources are assigned collectively to a group, the group members compete for the resources on a first-come, first-served (FCFS) basis. You can use hierarchical fairshare to further divide the shares among the group members.

  When resources are assigned to members of a group individually, the share assignment is recursive. Members of the group and of all subgroups always compete for the resources according to FCFS scheduling, regardless of hierarchical fairshare policies.

• number_shares

  Specify a positive integer representing the number of shares of the cluster resources assigned to the user.

  The number of shares assigned to each user is only meaningful when you compare it to the shares assigned to other users or to the total number of shares. The total number of shares is just the sum of all the shares assigned in each share assignment.

[ Top ]

---

User Section

Optional. If this section is not defined, all users and user groups can run an unlimited number of jobs in the cluster.

This section defines the maximum number of jobs a user or user group can run concurrently in the cluster. This is to avoid situations in which a user occupies all or most of the system resources while other users' jobs are waiting.

Structure

All three fields are mandatory: USER_NAME, MAX_JOBS, JL/P.

You must specify a dash (-) to indicate the default value (unlimited) if a user or user group is specified. Fields cannot be left blank.

Example of a User Section

Begin User
USER_NAME   MAX_JOBS   JL/P
user1       10          -
user2        4          1
user3        -          2
groupA@     10          1
default      6          1
End User

USER_NAME

User or user group for which job slot limits are defined.

Use the reserved user name default to specify a job slot limit that applies to each user and user group not explicitly named. Since the limit specified with the keyword default applies to user groups also, make sure you select a limit that is high enough, or explicitly define limits for user groups.

User group names can be the LSF user groups defined previously, and/or UNIX and Windows user groups.

Job slot limits apply to a group as a whole. Append the at sign (@) to a group name to make the job slot limits apply individually to each user in the group. If a group contains a subgroup, the job slot limit also applies to each member in the subgroup recursively.

If the group contains the keyword all in the user list, the at sign (@) has no effect. To specify job slot limits for each user in a user group containing all, use the keyword default.

MAX_JOBS

Per-user or per-group job slot limit for the cluster. Total number of job slots that each user or user group can use in the cluster.

JL/P

Per processor job slot limit per user or user group.

Total number of job slots that each user or user group can use per processor. This job slot limit is configured per processor so that multiprocessor hosts will automatically run more jobs.

This number can be a fraction such as 0.5, so that it can also serve as a per- host limit. This number is rounded up to the nearest integer equal to or greater than the total job slot limits for a host. For example, if JL/P is 0.5, on a 4-CPU multiprocessor host, the user can only use up to 2 job slots at any time. On a uniprocessor machine, the user can use 1 job slot.

[ Top ]

---

UserMap Section

Optional. Used only in a MultiCluster environment.

Defines system-level account mapping for users and user groups.

To support the execution of batch jobs across non-uniform user name spaces between clusters, LSF allows user account mapping. For a job submitted by one user account in one cluster to run under a different user account in a remote cluster, both the local and remote clusters must have the account mapping properly configured.

Structure

All three fields LOCAL, REMOTE and DIRECTION are required.

Example of a UserMap Section

On cluster1

Begin UserMap
LOCAL    REMOTE                             DIRECTION
user1    user2@cluster2                     export
user3    (user4@cluster2 user6@cluster2)    export
End UserMap

On cluster2

Begin UserMap
LOCAL            REMOTE                   DIRECTION
user2            user1@cluster1           import
(user6 user8)    user3@cluster1           import
End UserMap

Cluster1 configures user1 to run jobs as user2 and user3 to run jobs as user4 or user6.

Cluster2 configures user1 to run jobs as user2 and user3 to run jobs as user6 or user8.

Only mappings configured in both clusters will work. The common account mappings are for user1 to run jobs as user2 and for user3 to run jobs as user6. Therefore, these mappings will work, but the mappings of user3 to user4 and user8 are only half-done and so will not work.

LOCAL

A list of users or user groups in the local cluster.

Multiple user names and user group names must be separated by a space, and the entire list enclosed in parentheses ().

REMOTE

A list of remote users or user groups in the form: user_name@cluster_name
user_group_name@cluster_name

Multiple user names and user group names must be separated by a space, and the entire list enclosed in parentheses ().

DIRECTION

Configures the direction of account mapping:

• The export keyword configures local users/groups to run jobs as remote users/groups.
• The import keyword configures remote users/groups to run jobs as local users/groups.

Both directions must be configured for a mapping to work. The mapping must be configured in both the local and remote clusters.

[ Top ]

---

SEE ALSO

lsf.cluster(5), lsf.conf(5), lsb.params(5), lsb.hosts(5), lsb.queues(5), bhosts(1), bmgroup(1), bhpart(1), busers(1), bugroup(1), bqueues(1), bsub(1), bchkpnt(1), lsid(1), nice(1), getgrnam(3), mbatchd(8), badmin(8)

[ Top ]

---

[ Platform Documentation ]

[ Title ]

[ Contents ]

[ Previous ]

[ Next ]

[ Index ]

---

Date Modified: February 24, 2004 Platform Computing: www.platform.com Platform Support: support@platform.com Platform Information Development: doc@platform.com Copyright © 1994-2004 Platform Computing Corporation. All rights reserved.