Solaris Resource Manager 1.3 ご使用にあたって

バグ情報

Solaris オリジナルのマニュアルページが表示できない (バグ ID: 4208264)

Solaris 2.6 上において Solaris Resource Manager と同じ名前をもつ Solaris オリジナルのマニュアルページを表示するには、次のような指定をします。
% man brk.2
あるいは、英語版のマニュアルページ SUNWsrmm パッケージを pkgrm してから、次のように -s オプションを使用します。
% man -s 2 brk
nolnode スクリプトを実行すると、サーバーの性能が大幅に低下する (Solaris 2.6 システムだけ) (バグ ID: 4191045)

l ノードを持たないユーザーがシステムにログインすると、システムは nolnode スクリプトを実行し、そのユーザー用の l ノードを作成します。l ノードを持たない多数のユーザーが同時にログインすると、l ノードの作成で競合状態になることがあります。l ノードを持たない多数のユーザーがログインしようとすることが予測される場合、システム管理者はそれらのユーザー用の l ノードを前もって作成しておいてください。スクリプトを使用して l ノードを作成する方法については、/usr/srm/unsupport/passwd_lnodes を参照してください。
limreport: {...} を使用した日付の構文でコアダンプが発生する (Solaris 2.6 システムだけ) (バグ ID: 4191121)

次の構文は使用しないでください。

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

次の構文を使用してください。

limreport 'lastused > 1998/11/1812:00' '%s %f \n' lname cpu.usage
マルチプロセッサおよびシングルプロセッサシステムで、srmuser の制御下で起動したプロセスが正しくスケジュールされない (Solaris 2.6 システムだけ) (バグ ID: 4191878)

この問題は、ksh(1) を使用して srmuser(1SRM) とともにバックグラウンドでアプリケーションを起動したときに発生します。たとえば、userA が ksh を使用して、次のコマンドをバックグランドで実行した場合、userB は CPU を使用するとはみなされません。
# srmuser userB job &
この問題を回避するには、sh(1) または csh(1) を使用するか、srmuser をフォアグラウンドで実行します。
# srmuser userB job
limreport: limadm set -f で preserve の出力を利用できない (Solaris 2.6 システムだけ) (バグ ID: 4191130)

limreport コマンドの preserve オプションの出力では、属性がコンマで区切られます。これに対して、limadm set -f で入力する場合は、コロンである必要があります。

この問題を回避するには、次の例に示すように limreport の出力を sed 's/,/:/g にパイプ処理で渡してください。
# limreport 'lname=="u1"' - lname preserve | sed 's/,/:/g' | limadm set -f -
limadm が日付属性を設定できない (Solaris 2.6 システムだけ) (バグ ID: 4191891)

この問題によって、製品の機能が影響を受けることはありません。
Solaris Resource Manager の壊れたデータベースが報告なしに無視されるか、上書きされる (Solaris 2.6 システムだけ) (バグ ID: 4193731)

システムパニックまたはハングの後 fsck の実行などで /var/srm/srmDB の l ノードデータベースファイルが上書きされた場合、Solaris Resource Manager は、root の l ノードで障害が発生しない限り、リブート中にデータベースの障害を検知することはありません。(Solaris Resource Manager は、1 ノードデータベースが削除されていたり途中でなくなっていたりしても検知できません。) 問題が検知されなかった場合、データベースを削除したり、ファイルサイズを 0 に切り詰めない限り、システムは壊れたデータベースをそのままにして報告なしにリブートします。そしてリブートの際に、デフォルトのファイルで報告なしに /var/srm/srmDB を上書きします。したがって、システムのコピーが破壊されたり、間違って削除されたりする場合に備えて、/var/srm/srmDB ファイルの最新コピーを常にバックアップしておく必要があります。このようにすれば、データベースの問題が原因となるダウンタイムは最小限に抑えられます。

注 -
Solaris Resource Manager が使用できない、あるいはデータベースが開けない場合には、システムが障害を検知したことが分かります。この場合でも、Solaris Resource Manager を使用する前に、壊れたデータベースを最新バージョンのバックアップで置換する必要があります。
liminfo -c で terminal.usage と terminal.accrue が動作しない (バグ ID: 4255564)

Solaris Resource Manager をインストールして初めてマシンをブートすると、l ノードデータベース /var/srm/srmDB が作成される直後であるため、limdaemon プログラムは terminal.usage と terminal.accrue の l ノード属性を更新しません。既存の l ノードデータベースファイルでシステムをリブートできない場合は、次の手順に従ってください。
1. スーパーユーザーになります。
2. 現在実行されている limdaemon を終了します。
  # /usr/srm/lib/limdaemon -k
3. limdaemon を再実行します。
  # /usr/srm/lib/limdaemon
デーモンがルートの l ノードに接続される (バグ ID: 4189560)
srm をサポートするように、/etc/rc2 および /etc/rc3 を修正する必要がある (バグ ID: 4189582)

『Solaris Resource Manager 1.3 のシステム管理』の第 10 章「問題の解決」およびバグ ID 4189560 で、プロセス (特にシステムデーモン) が root の l ノードに接続して動作することが許可されている場合に発生する可能性がある問題について説明しています。上記のマニュアルでは、この問題を回避するために、すべてのシステム初期設定スクリプト内のデーモンプロセスを起動するコマンドに srmuser(1SRM) コマンドを追加するよう推奨しています。ただし、この方法では大量のファイルを編集する必要があるため、作業が大変で、後でシステムにパッチを組み込むことができなくなる可能性もあります。したがって、この解決方法を通常使用することは推奨できません。

Solaris Resource Manager 1.0 以降のリリースでは、/usr/srm/unsupport ディレクトリにある sbin_rc2 と sbin_rc3 というスクリプトを使用すると、この問題を部分的に解決できます
l ノードキャッシュが一杯になると、Solaris Resource Manager がパニックを起こす (バグ ID: 4192645)

カーネルには、動作中のユーザーごとに 1 つの l ノードが存在し、Solaris Resource Manager の初期化中に l ノードキャッシュが割り当てられます。このキャッシュのサイズは、設定可能なパラメータの SRMLnodes の値によって異なります。SRMLnodes のデフォルト値は、次の式で計算します。
SRMLnodes = nproc/ShareProcsPerUid + ShareLnodesExtra
ShareProcsPerUid のデフォルト値は 4、ShareLnodesExtra のデフォルト値は 20 です。動作中のユーザー数が SRMLnodes の値を超えると、システムがパニックを起こします。

この問題を回避するには、SRMLnodes の値を大きくします。