This output would be displayed from a liminfo listing of db1 at the end of the example in the previous section. Typing:
# liminfo db1
The first two lines of output from the liminfo command relate to aspects of the lnode UID and its position in the lnode tree:
The login name and initial GID from the password map that corresponds to the UID of the attached lnode. Every lnode is associated with a system UID. A system account should be created for the UID of every lnode. In this instance, a placeholder UID, db1, is used for Database1.
Note that the default PAM configuration under Solaris Resource Manager creates an lnode for any user who logs in without one. By default, lnodes created by the superuser or by a user with the uselimadm flag set are created with the lnode srmother as their parent, or if that does not exist, with the root lnode as their parent. The parent of an lnode can be changed with the command generally used to revise lnode attributes, limadm.
The UID of the lnode attached to the current process. Normally, this will be the same as that of the real UID of the process (the logged in user), but in some circumstances (described later) it may differ.
The GID of the lnode attached to the current process.
The real and effective UID and GID of the current process. This is the same information that is provided by the standard system id(1M) command. It is not strictly related to Solaris Resource Manager, but it is displayed for convenience. These fields are not displayed if liminfo is displaying information on a user other than the default (that is, if a login name or UID was given as an argument).
The name and UID of the parent lnode in the lnode tree hierarchy. This will be blank for the root lnode. Many Solaris Resource Manager features depend on the position of an lnode within the tree hierarchy, so it is useful for a user to trace successive parent lnodes back to the root of the tree.
After the blank line, the next three lines of the liminfo display show fields that relate to CPU scheduling:
This is the number of shares of CPU entitlement allocated to this user. It is only directly comparable to other users with the same parent lnode, and to the Myshares value of the parent lnode itself. Administrators might normally set the shares of all users within a particular scheduling group to the same value (giving those users equal entitlements). This value will normally be something greater than 1, so that administrators have some leeway to decrease the shares of specific users when appropriate.
This value is only used if this user has child lnodes (that is, if there are other lnodes that have an sgroup value of this user) that are active (that is, have processes attached). When this is the case, this value gives the relative share of CPU for processes attached to this lnode, compared with those attached to its child lnodes.
The calculated percentage of the system CPU resources to which the current user is entitled. As other users log in and log out (or lnodes become active or inactive), this value will change, because only active users are included in the calculation. Recent usage by the current user is not included in this calculation.
This is the effective share of this user (that is, the actual percentage of the system CPU resources that this user would be given in the short term if the user required it and all other active users were also demanding their share). It can be thought of as the current willingness of Solaris Resource Manager to allocate CPU resources to that lnode. This value will change over time as the user uses (or refrains from using) CPU resources. Lnodes that are active but idle (that is, with attached processes sleeping), and so have a low usage, will have a high effective share value. Correspondingly, the effective share can be very small for users with attached processes that are actively using the CPU.
The accumulated usage of system resources that are used to determine scheduling priority. Typically, this indicates recent CPU usage, though other parameters may also be taken into account. The parameter mix used can be viewed with the srmadm command. Each increment to this value decays exponentially over time so that Solaris Resource Manager will eventually "forget" about the resource usage. The rate of this decay is most easily represented by its half-life, which can be seen with the srmadm command.
This is the same resource accumulation measurement as cpu.usage, but it is never decayed. It is not used directly by Solaris Resource Manager but can be used by administration for accounting purposes. Unlike usage, this value represents the sum of the accrued usages for all lnodes within the group, as well as that of the current lnode.
After the second blank line, the next four lines of the liminfo listing show fields that relate to virtual memory and terminal usage:
This is the combined memory usage of all processes attached to this lnode.
If two values are displayed, separated by a frontslash (/) character, then this lnode is a group header. The first value is the usage for the whole scheduling group, while the second value is that of the current user only.
The maximum memory usage allowed for all processes attached to this lnode and its members (if any). That is, the sum of the memory usage for all processes within the group plus those attached to the group header will not be allowed to exceed this value. Note that in this instance, a value of zero (0) indicates that there is no limit.
The per-process memory limit is the maximum memory usage allowed for any single process attached to this lnode and its members.
The memory.accrue value is measured in byte-seconds and is an indication of overall memory resources used over a period of time.
The number of seconds of connect-time currently charged to the group.
The number of seconds of connect-time used by the group.
The maximum allowed value of the terminal.usage attribute. If zero, there is no limit, unless limited by inheritance.
After the third blank line, the next two lines of the liminfo listing display fields that relate to the user and processes:
The number of processes attached to this lnode. Note that this refers to processes, not a count of threads within a process.
If two values are displayed, separated by a frontslash (/) character, then this lnode is a group header and the first value is the usage for the whole scheduling group, while the second value is that of just the current user.
The maximum total number of processes allowed to be attached to this lnode and its members.
The current number of simultaneous Solaris Resource Manager login sessions for this user. When a user logs in through any of the standard system login mechanisms (including login(1), rlogin(1)-basically, anything that uses PAM for authentication and creates a utmp(4) entry), this counter is incremented. When the session ends, the count is decremented.
If a user's flag.onelogin flag evaluates to set, the user is only permitted to have a single Solaris Resource Manager login session.
After the fourth blank line, the next four lines of the liminfo display show these fields:
This field shows the last time the lnode was active. This will normally be the last time the user logged out.
The user's home directory (items from the password map rather than from Solaris Resource Manager are shown for convenience).
The db1 (finger) information, which is usually the user's name (items from the password map rather than from Solaris Resource Manager are shown for convenience).
The user's initial login shell (items from the password map rather than from Solaris Resource Manager are shown for convenience).
After the fifth blank line, the last line of the liminfo display shows this field:
Flags that evaluate to set or group in the lnode are displayed here. Each flag displayed is followed by suffix characters indicating the value and the way in which the flag was set (for example, whether it was explicitly from this lnode (+) or inherited (^)).