Bugs

• 4191045 (This bug is only applicable to Solaris 2.6 systems.) The script nolnode could decrease server performance significantly

  When a user without an lnode logs in to the system, the system executes the nolnode script to create an lnode for the user. When there are a large number of users without lnode logins who log in at the same time, the lnode creation may become a contention. If the system administrator expects that a large number of users without lnodes will be logging in, he should create the lnodes for the users ahead of time. Refer to /usr/srm/unsupport/passwd_lnodes for information on how to create lnodes using a script.

• 4191121 (This bug is only applicable to Solaris 2.6 systems.) limreport: Expression syntax for date using {...} dumps core

  Do not use:

  limreport 'lastused > {1998111812:00}' '%s %f \n' lname cpu.usage

  Do use:

  limreport 'lastused > 1998/11/1812:00' '%s %f \n' lname cpu.usage

• 4191878 (This bug is only applicable to Solaris 2.6 systems.) Processes started under srmuser are not scheduled properly on multi-processor and single-processor systems

  This problem occurs when you start an application in the background with srmuser(1SRM), using ksh(1). For example, if userA runs:

  # srmuser userB job &

  in the background using ksh, the CPU usage will not be charged to userB. The workaround for this problem is to use sh(1) or csh(1), or run the srmuser command in the foreground:

  # srmuser userB job

• 4191130 (This bug is only applicable to Solaris 2.6 systems.) limreport: preserve output incompatible with limadm set -f

  The output of the limreport command's preserve option separates attributes with a comma. However, the input to limadm set -f requires colons.

  The workaround is to pipe the output of limreport through "sed 's/,/:/g" as shown in this example:

  # limreport 'lname=="u1"' - lname preserve | sed 's/,/:/g' | limadm set -f -

• 4191891 (This bug is only applicable to Solaris 2.6 systems.) limadm fails to set date attributes

  This doesn't affect the product functionality.

• 4193731 (This bug is only applicable to Solaris 2.6 systems.) Corrupt Solaris Resource Manager database will be silently ignored or overwritten

  If the /var/srm/srmDB lnode database file is overwritten, such as during an fsck after a system panic or hang, Solaris Resource Manager will not detect the corruption during reboot unless it occured in the root lnode. (Solaris Resource Manager cannot detect the removal or truncation of the lnode database.) If no problem is detected, the system will silently reboot with the corrupted database, unless it has been removed or truncated to a file of size 0; then the system will silently overwrite /var/srm/srmDB with a default version of the file on reboot. Therefore, you should always keep a backup copy of the latest /var/srm/srmDB file in case the system copy becomes corrupted or is mistakenly removed. This will minimize downtime due to database problems.

  ---

  Note -

  You will know that corruption has been detected by the system if it does not enable Solaris Resource Manager or open the database. You will still have to replace the corrupted database with a backup of the latest working version before you can enable Solaris Resource Manager functionality.

  ---

• 4255564 terminal.usage and terminal.accrue not working for liminfo -c

  When a machine is booted for the first time with Solaris Resource Manager installed, the limdaemon program does not get to the point where it updates the terminal.usage and terminal.accrue lnode attributes since the lnode database /var/srm/srmDB has just been created. If you can't reboot your system with an existing lnode database file, try the following workaround:

  1. Become root.

  2. Terminate the currently running limdaemon:

     # /usr/srm/lib/limdaemon -k

  3. Run limdaemon again:

     # /usr/srm/lib/limdaemon

• 4189560 Daemons shouldn't be attached to root lnodes

• 4189582 /etc/rc2 and /etc/rc3 need to be modified to support srm

  Chapter 10, "Troubleshooting," of the Solaris Resource Manager 1.3 System Administration Guide and bugid 4189560 describe the problems that can arise if processes (particularly system daemons) are allowed to run attached to the root lnode. The guide suggests editing the system initialization scripts to add an srmuser(1SRM) command to commands that start a daemon process. However, this can be a burden since a large number of files need to be edited, and the practice could inhibit the ability to integrate patches into a system later. Therefore, this solution cannot be routinely recommended.

  For Solaris Resource Manager releases after 1.0, the scripts sbin_rc2 and sbin_rc3 provided in the /usr/srm/unsupport directory can be used to partially solve this problem.

• 4192645 Solaris Resource Manager panics when the lnode cache is full

  For every active user there is an lnode in the kernel. There is a cache of lnodes allocated during the initialization of Solaris Resource Manager. The cache size depends on the tunable parameter SRMLnodes. The default value of SRMLnodes is calculated as follows:

  SRMLnodes = nproc/ShareProcsPerUid + ShareLnodesExtra

  The default value of ShareProcsPerUid is 4 and that of ShareLnodesExtra is 20. When the number of active users exceeds the value in SRMLnodes, the system panics.

  The workaround is to tune SRMLnodes, using a higher value.