[インデックス 18630] ファイルの概要

このコミットは、Go言語のランタイムにおけるrun.bashスクリプトの変更に関するものです。具体的には、ulimitコマンドの実行に関するコメントが追加され、潜在的な問題とその原因について説明されています。

コミット

commit e6e894500171ee8013713f76660076632f1b355c
Author: Russ Cox <rsc@golang.org>
Date:   Mon Feb 24 16:44:35 2014 -0500

    build: comment possible ulimit failure in run.bash
    
    Record what's going on in case someone is debugging a failure there.
    It's not Go's fault.
    
    Fixes #7381.
    
    LGTM=bradfitz
    R=golang-codereviews, bradfitz
    CC=golang-codereviews
    https://golang.org/cl/68200043

GitHub上でのコミットページへのリンク

https://github.com/golang/go/commit/e6e894500171ee8013713f76660076632f1b355c

元コミット内容

build: comment possible ulimit failure in run.bash

Record what's going on in case someone is debugging a failure there.
It's not Go's fault.

Fixes #7381.

LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/68200043

変更の背景

このコミットの背景には、Go言語のビルドシステムで使用されるrun.bashスクリプトが、特定のシステム環境下でulimitコマンドの実行に失敗する問題がありました。ulimitは、プロセスが利用できるシステムリソース（ファイルディスクリプタ数、メモリ量など）を制限するためのコマンドです。Goのビルドプロセスでは、多くのファイルディスクリプタやメモリを必要とすることがあり、これらのリソース制限が適切に設定されていないと、ビルドが失敗する可能性がありました。

特に、ulimit -S -nコマンド（ソフトリミットのファイルディスクリプタ数を設定）が、ulimit -H -n（ハードリミットのファイルディスクリプタ数）よりも高い値に設定されている場合に失敗するという報告がありました。これは、非rootユーザーがハードリミットを超えるソフトリミットを設定しようとすると発生する問題で、Goのコード自体に問題があるわけではなく、オペレーティングシステム（OS）側の設定に起因するものでした。

開発者がこの問題に遭遇した際に、Goのビルドシステムが原因であると誤解するのを防ぐため、そしてデバッグの手助けとなるように、この挙動に関する説明をrun.bashスクリプト内に明示的に追加することが決定されました。これにより、ユーザーは問題がGoのバグではなく、自身のシステム設定にあることを理解し、適切な対処を行うことができるようになります。

前提知識の解説

ulimitコマンド

ulimitは、Unix系OSにおいて、ユーザーが実行するプロセスのリソース制限を設定または表示するためのシェル組み込みコマンドです。主なリソース制限には以下のようなものがあります。

• ファイルディスクリプタ数 (-n): プロセスが開くことができるファイルの最大数。
• コアファイルサイズ (-c): プロセスがクラッシュした際に生成されるコアダンプファイルの最大サイズ。
• データセグメントサイズ (-d): プロセスが使用できるデータセグメントの最大サイズ。
• 仮想メモリサイズ (-v): プロセスが使用できる仮想メモリの最大サイズ。

ulimitには「ソフトリミット (soft limit)」と「ハードリミット (hard limit)」の2種類があります。

• ソフトリミット (-S): 現在適用されているリミットで、ユーザーはこれをハードリミットの範囲内で自由に引き上げることができます。
• ハードリミット (-H): ソフトリミットの最大値で、非rootユーザーはこれを引き上げることはできません（rootユーザーのみが引き上げ可能）。

このコミットで言及されている問題は、非rootユーザーがソフトリミットをハードリミットよりも高い値に設定しようとした場合に発生します。これは通常、システム管理者が/etc/security/limits.confなどの設定ファイルで、ユーザーが設定できるハードリミットを意図的に低く設定している場合に起こりえます。

run.bashスクリプト

run.bashは、Go言語のソースコードリポジトリに含まれるシェルスクリプトで、Goのビルド、テスト、およびその他の開発関連タスクを実行するために使用されます。このスクリプトは、Goの開発環境をセットアップし、Goのツールチェーンをビルドし、テストを実行する際の初期設定の一部としてulimitコマンドを実行します。

Goのビルドプロセスとリソース要件

Goのコンパイラやリンカは、大規模なプロジェクトをビルドする際に、多数のファイルを開いたり、大量のメモリを使用したりすることがあります。特に、並行ビルドや大規模なテストスイートの実行時には、多くのファイルディスクリプタが必要となることがあります。そのため、run.bashスクリプトは、これらのリソース制限を適切に設定することで、ビルドプロセスの安定性とパフォーマンスを確保しようとします。

Issue #7381

Fixes #7381という記述は、このコミットがGoのIssueトラッカーにおける7381番の課題を解決することを示しています。このIssueは、まさにulimit -S -nが特定の環境で失敗する問題について議論されたもので、Goのビルドが失敗する原因がGo自体ではなく、OSのリソース制限設定にあることを明確にする必要性が提起されていました。

技術的詳細

このコミットは、src/run.bashファイルにコメントを追加するだけの、非常にシンプルな変更です。しかし、その背後には、Goのビルドシステムが直面する可能性のある環境依存の問題に対する理解と、ユーザーエクスペリエンスの向上が意図されています。

変更されたコードは以下の部分です。

# Raise soft limits to hard limits for NetBSD/OpenBSD.
# We need at least 256 files and ~300 MB of bss.
# On OS X ulimit -S -n rejects 'unlimited'.
#
# Note that ulimit -S -n may fail if ulimit -H -n is set higher than a
# non-root process is allowed to set the high limit.
# This is a system misconfiguration and should be fixed on the
# broken system, not "fixed" by ignoring the failure here.
# See longer discussion on golang.org/issue/7381. 
[ "$(ulimit -H -n)" == "unlimited" ] || ulimit -S -n $(ulimit -H -n)
[ "$(ulimit -H -d)" == "unlimited" ] || ulimit -S -d $(ulimit -H -d)

追加されたコメントは、ulimit -S -nコマンドが失敗する可能性のあるシナリオを具体的に説明しています。

1. 失敗の条件: 「ulimit -S -nは、非rootプロセスがハイリミット（ハードリミット）を設定することを許可されている値よりもulimit -H -nが高い場合に失敗する可能性がある」と述べています。これは、システムがユーザーに対して設定を許可している最大値（ハードリミット）よりも、実際に設定されているハードリミットが高い場合に、ソフトリミットをハードリミットに合わせようとするとエラーになることを意味します。
2. 原因の特定: この問題は「システムの誤設定」であると明確に指摘しています。つまり、Goのコードやビルドスクリプトに問題があるのではなく、OSレベルでのリソース制限の設定に不整合があることが原因であると断言しています。
3. 解決策の提示: 「これは壊れたシステムで修正されるべきであり、ここ（Goのスクリプト）で失敗を無視することで"修正"されるべきではない」と強調しています。これは、Goの開発チームがこの問題をGoのコードで回避するのではなく、ユーザーが自身のシステム設定を修正すべきであるという方針を示しています。
4. 詳細情報への誘導: golang.org/issue/7381への参照を提供することで、この問題に関するより詳細な議論や背景情報をユーザーが確認できるようにしています。

この変更は、コードの動作自体には影響を与えませんが、デバッグの際に非常に役立つ情報を提供し、Goのビルドプロセスにおける一般的な誤解を解消するのに貢献します。

コアとなるコードの変更箇所

変更はsrc/run.bashファイルのみです。

--- a/src/run.bash
+++ b/src/run.bash
@@ -17,6 +17,12 @@ ulimit -c 0
 # Raise soft limits to hard limits for NetBSD/OpenBSD.
 # We need at least 256 files and ~300 MB of bss.
 # On OS X ulimit -S -n rejects 'unlimited'.
+#
+# Note that ulimit -S -n may fail if ulimit -H -n is set higher than a
+# non-root process is allowed to set the high limit.
+# This is a system misconfiguration and should be fixed on the
+# broken system, not "fixed" by ignoring the failure here.
+# See longer discussion on golang.org/issue/7381. 
 [ "$(ulimit -H -n)" == "unlimited" ] || ulimit -S -n $(ulimit -H -n)
 [ "$(ulimit -H -d)" == "unlimited" ] || ulimit -S -d $(ulimit -H -d)
 

具体的には、ulimit -S -nおよびulimit -S -dを設定する行の直前に、6行のコメントが追加されています。

コアとなるコードの解説

追加されたコメントは、ulimitコマンドの挙動に関する重要な注意書きです。

• ulimit -c 0: コアファイルの生成を無効にしています。これは、クラッシュ時に大きなコアダンプファイルが生成されるのを防ぎ、ディスクスペースの消費を抑えるためによく行われます。

• # Raise soft limits to hard limits for NetBSD/OpenBSD.: NetBSDやOpenBSDのような一部のシステムでは、ソフトリミットをハードリミットまで引き上げる必要があることを示唆しています。

• # We need at least 256 files and ~300 MB of bss.: Goのビルドプロセスが少なくとも256個のファイルディスクリプタと約300MBのBSS（未初期化データセグメント）を必要とすることを示しています。これは、Goのビルドが要求する最低限のリソース要件の目安となります。

• # On OS X ulimit -S -n rejects 'unlimited'.: macOS（旧OS X）では、ulimit -S -n unlimitedという形式が受け入れられないというOS固有の注意点です。

• 追加されたコメントブロック:

  • # Note that ulimit -S -n may fail if ulimit -H -n is set higher than a
  • # non-root process is allowed to set the high limit.
    • この2行は、非rootユーザーがulimit -H -nで設定された値よりも高いソフトリミットを設定しようとした場合に、ulimit -S -nが失敗する可能性があることを説明しています。これは、システムがユーザーに許可している最大値（ハードリミット）と、実際に設定されているハードリミットの間に不整合がある場合に発生します。
  • # This is a system misconfiguration and should be fixed on the
  • # broken system, not "fixed" by ignoring the failure here.
    • この問題がGoのバグではなく、OSのシステム設定の誤りであることを明確にしています。そして、Goのスクリプト側でこのエラーを無視して回避するのではなく、根本原因であるシステム設定を修正すべきであるというGo開発チームのスタンスを示しています。
  • # See longer discussion on golang.org/issue/7381. :
    • この問題に関する詳細な議論や背景情報がGoのIssueトラッカーの7381番で確認できることを示しています。

• [ "$(ulimit -H -n)" == "unlimited" ] || ulimit -S -n $(ulimit -H -n):

  • 現在のハードリミットのファイルディスクリプタ数（ulimit -H -n）が"unlimited"でない場合、ソフトリミットのファイルディスクリプタ数（ulimit -S -n）をハードリミットの値に設定します。これにより、Goのビルドプロセスが利用できるファイルディスクリプタ数を最大化しようとします。

• [ "$(ulimit -H -d)" == "unlimited" ] || ulimit -S -d $(ulimit -H -d):

  • 同様に、現在のハードリミットのデータセグメントサイズ（ulimit -H -d）が"unlimited"でない場合、ソフトリミットのデータセグメントサイズ（ulimit -S -d）をハードリミットの値に設定します。

このコミットは、コードの機能的な変更ではなく、ドキュメンテーションの改善であり、ユーザーがGoのビルド環境で遭遇する可能性のある特定の問題に対する理解を深めることを目的としています。

関連リンク

• Go Issue 7381: https://golang.org/issue/7381
• Go Code Review 68200043: https://golang.org/cl/68200043

参考にした情報源リンク

• ulimit man page (Unix/Linuxシステム): man ulimit
• Go言語の公式ドキュメントおよびソースコード
• Go Issue 7381の議論スレッド
• Go Code Review 68200043のレビューコメント
• 一般的なUnix/Linuxシステム管理に関する情報源（ulimit、リソース制限に関する解説）

[インデックス 18630] ファイルの概要

このコミットは、Go言語のランタイムにおけるrun.bashスクリプトの変更に関するものです。具体的には、ulimitコマンドの実行に関するコメントが追加され、潜在的な問題とその原因について説明されています。

コミット

commit e6e894500171ee8013713f76660076632f1b355c
Author: Russ Cox <rsc@golang.org>
Date:   Mon Feb 24 16:44:35 2014 -0500

    build: comment possible ulimit failure in run.bash
    
    Record what's going on in case someone is debugging a failure there.
    It's not Go's fault.
    
    Fixes #7381.
    
    LGTM=bradfitz
    R=golang-codereviews, bradfitz
    CC=golang-codereviews
    https://golang.org/cl/68200043

GitHub上でのコミットページへのリンク

https://github.com/golang/go/commit/e6e894500171ee8013713f76660076632f1b355c

元コミット内容

build: comment possible ulimit failure in run.bash

Record what's going on in case someone is debugging a failure there.
It's not Go's fault.

Fixes #7381.

LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/68200043

変更の背景

このコミットの背景には、Go言語のビルドシステムで使用されるrun.bashスクリプトが、特定のシステム環境下でulimitコマンドの実行に失敗する問題がありました。ulimitは、プロセスが利用できるシステムリソース（ファイルディスクリプタ数、メモリ量など）を制限するためのコマンドです。Goのビルドプロセスでは、多くのファイルディスクリプタやメモリを必要とすることがあり、これらのリソース制限が適切に設定されていないと、ビルドが失敗する可能性がありました。

特に、ulimit -S -nコマンド（ソフトリミットのファイルディスクリプタ数を設定）が、ulimit -H -n（ハードリミットのファイルディスクリプタ数）よりも高い値に設定されている場合に失敗するという報告がありました。これは、非rootユーザーがハードリミットを超えるソフトリミットを設定しようとすると発生する問題で、Goのコード自体に問題があるわけではなく、オペレーティングシステム（OS）側の設定に起因するものでした。

開発者がこの問題に遭遇した際に、Goのビルドシステムが原因であると誤解するのを防ぐため、そしてデバッグの手助けとなるように、この挙動に関する説明をrun.bashスクリプト内に明示的に追加することが決定されました。これにより、ユーザーは問題がGoのバグではなく、自身のシステム設定にあることを理解し、適切な対処を行うことができるようになります。

前提知識の解説

ulimitコマンド

ulimitは、Unix系OSにおいて、ユーザーが実行するプロセスのリソース制限を設定または表示するためのシェル組み込みコマンドです。主なリソース制限には以下のようなものがあります。

• ファイルディスクリプタ数 (-n): プロセスが開くことができるファイルの最大数。
• コアファイルサイズ (-c): プロセスがクラッシュした際に生成されるコアダンプファイルの最大サイズ。
• データセグメントサイズ (-d): プロセスが使用できるデータセグメントの最大サイズ。
• 仮想メモリサイズ (-v): プロセスが使用できる仮想メモリの最大サイズ。

ulimitには「ソフトリミット (soft limit)」と「ハードリミット (hard limit)」の2種類があります。

• ソフトリミット (-S): 現在適用されているリミットで、ユーザーはこれをハードリミットの範囲内で自由に引き上げることができます。
• ハードリミット (-H): ソフトリミットの最大値で、非rootユーザーはこれを引き上げることはできません（rootユーザーのみが引き上げ可能）。

このコミットで言及されている問題は、非rootユーザーがソフトリミットをハードリミットよりも高い値に設定しようとした場合に発生します。これは通常、システム管理者が/etc/security/limits.confなどの設定ファイルで、ユーザーが設定できるハードリミットを意図的に低く設定している場合に起こりえます。

run.bashスクリプト

run.bashは、Go言語のソースコードリポジトリに含まれるシェルスクリプトで、Goのビルド、テスト、およびその他の開発関連タスクを実行するために使用されます。このスクリプトは、Goの開発環境をセットアップし、Goのツールチェーンをビルドし、テストを実行する際の初期設定の一部としてulimitコマンドを実行します。

Goのビルドプロセスとリソース要件

Goのコンパイラやリンカは、大規模なプロジェクトをビルドする際に、多数のファイルを開いたり、大量のメモリを使用したりすることがあります。特に、並行ビルドや大規模なテストスイートの実行時には、多くのファイルディスクリプタが必要となることがあります。そのため、run.bashスクリプトは、これらのリソース制限を適切に設定することで、ビルドプロセスの安定性とパフォーマンスを確保しようとします。

Issue #7381

Fixes #7381という記述は、このコミットがGoのIssueトラッカーにおける7381番の課題を解決することを示しています。このIssueは、まさにulimit -S -nが特定の環境で失敗する問題について議論されたもので、Goのビルドが失敗する原因がGo自体ではなく、OSのリソース制限設定にあることを明確にする必要性が提起されていました。

技術的詳細

このコミットは、src/run.bashファイルにコメントを追加するだけの、非常にシンプルな変更です。しかし、その背後には、Goのビルドシステムが直面する可能性のある環境依存の問題に対する理解と、ユーザーエクスペリエンスの向上が意図されています。

変更されたコードは以下の部分です。

# Raise soft limits to hard limits for NetBSD/OpenBSD.
# We need at least 256 files and ~300 MB of bss.
# On OS X ulimit -S -n rejects 'unlimited'.
#
# Note that ulimit -S -n may fail if ulimit -H -n is set higher than a
# non-root process is allowed to set the high limit.
# This is a system misconfiguration and should be fixed on the
# broken system, not "fixed" by ignoring the failure here.
# See longer discussion on golang.org/issue/7381. 
[ "$(ulimit -H -n)" == "unlimited" ] || ulimit -S -n $(ulimit -H -n)
[ "$(ulimit -H -d)" == "unlimited" ] || ulimit -S -d $(ulimit -H -d)

追加されたコメントは、ulimit -S -nコマンドが失敗する可能性のあるシナリオを具体的に説明しています。

1. 失敗の条件: 「ulimit -S -nは、非rootプロセスがハイリミット（ハードリミット）を設定することを許可されている値よりもulimit -H -nが高い場合に失敗する可能性がある」と述べています。これは、システムがユーザーに対して設定を許可している最大値（ハードリミット）と、実際に設定されているハードリミットの間に不整合がある場合に、ソフトリミットをハードリミットに合わせようとするとエラーになることを意味します。
2. 原因の特定: この問題は「システムの誤設定」であると明確に指摘しています。つまり、Goのコードやビルドスクリプトに問題があるのではなく、OSレベルでのリソース制限の設定に不整合があることが原因であると断言しています。
3. 解決策の提示: 「これは壊れたシステムで修正されるべきであり、ここ（Goのスクリプト）で失敗を無視することで"修正"されるべきではない」と強調しています。これは、Goの開発チームがこの問題をGoのコードで回避するのではなく、ユーザーが自身のシステム設定を修正すべきであるという方針を示しています。
4. 詳細情報への誘導: golang.org/issue/7381への参照を提供することで、この問題に関するより詳細な議論や背景情報をユーザーが確認できるようにしています。

この変更は、コードの動作自体には影響を与えませんが、デバッグの際に非常に役立つ情報を提供し、Goのビルドプロセスにおける一般的な誤解を解消するのに貢献します。

コアとなるコードの変更箇所

変更はsrc/run.bashファイルのみです。

--- a/src/run.bash
+++ b/src/run.bash
@@ -17,6 +17,12 @@ ulimit -c 0
 # Raise soft limits to hard limits for NetBSD/OpenBSD.
 # We need at least 256 files and ~300 MB of bss.
 # On OS X ulimit -S -n rejects 'unlimited'.
+#
+# Note that ulimit -S -n may fail if ulimit -H -n is set higher than a
+# non-root process is allowed to set the high limit.
+# This is a system misconfiguration and should be fixed on the
+# broken system, not "fixed" by ignoring the failure here.
+# See longer discussion on golang.org/issue/7381. 
 [ "$(ulimit -H -n)" == "unlimited" ] || ulimit -S -n $(ulimit -H -n)
 [ "$(ulimit -H -d)" == "unlimited" ] || ulimit -S -d $(ulimit -H -d)
 

具体的には、ulimit -S -nおよびulimit -S -dを設定する行の直前に、6行のコメントが追加されています。

コアとなるコードの解説

追加されたコメントは、ulimitコマンドの挙動に関する重要な注意書きです。

• ulimit -c 0: コアファイルの生成を無効にしています。これは、クラッシュ時に大きなコアダンプファイルが生成されるのを防ぎ、ディスクスペースの消費を抑えるためによく行われます。

• # Raise soft limits to hard limits for NetBSD/OpenBSD.: NetBSDやOpenBSDのような一部のシステムでは、ソフトリミットをハードリミットまで引き上げる必要があることを示唆しています。

• # We need at least 256 files and ~300 MB of bss.: Goのビルドプロセスが少なくとも256個のファイルディスクリプタと約300MBのBSS（未初期化データセグメント）を必要とすることを示しています。これは、Goのビルドが要求する最低限のリソース要件の目安となります。

• # On OS X ulimit -S -n rejects 'unlimited'.: macOS（旧OS X）では、ulimit -S -n unlimitedという形式が受け入れられないというOS固有の注意点です。

• 追加されたコメントブロック:

  • # Note that ulimit -S -n may fail if ulimit -H -n is set higher than a
  • # non-root process is allowed to set the high limit.
    • この2行は、非rootユーザーがulimit -H -nで設定された値よりも高いソフトリミットを設定しようとした場合に、ulimit -S -nが失敗する可能性があることを説明しています。これは、システムがユーザーに許可している最大値（ハードリミット）と、実際に設定されているハードリミットの間に不整合がある場合に発生します。
  • # This is a system misconfiguration and should be fixed on the
  • # broken system, not "fixed" by ignoring the failure here.
    • この問題がGoのバグではなく、OSのシステム設定の誤りであることを明確にしています。そして、Goのスクリプト側でこのエラーを無視して回避するのではなく、根本原因であるシステム設定を修正すべきであるというGo開発チームのスタンスを示しています。
  • # See longer discussion on golang.org/issue/7381. :
    • この問題に関する詳細な議論や背景情報がGoのIssueトラッカーの7381番で確認できることを示しています。

• [ "$(ulimit -H -n)" == "unlimited" ] || ulimit -S -n $(ulimit -H -n):

  • 現在のハードリミットのファイルディスクリプタ数（ulimit -H -n）が"unlimited"でない場合、ソフトリミットのファイルディスクリプタ数（ulimit -S -n）をハードリミットの値に設定します。これにより、Goのビルドプロセスが利用できるファイルディスクリプタ数を最大化しようとします。

• [ "$(ulimit -H -d)" == "unlimited" ] || ulimit -S -d $(ulimit -H -d):

  • 同様に、現在のハードリミットのデータセグメントサイズ（ulimit -H -d）が"unlimited"でない場合、ソフトリミットのデータセグメントサイズ（ulimit -S -d）をハードリミットの値に設定します。

このコミットは、コードの機能的な変更ではなく、ドキュメンテーションの改善であり、ユーザーがGoのビルド環境で遭遇する可能性のある特定の問題に対する理解を深めることを目的としています。

関連リンク

• Go Issue 7381: https://golang.org/issue/7381
• Go Code Review 68200043: https://golang.org/cl/68200043

参考にした情報源リンク

• ulimit man page (Unix/Linuxシステム): man ulimit
• Go言語の公式ドキュメントおよびソースコード
• Go Issue 7381の議論スレッド
• Go Code Review 68200043のレビューコメント
• 一般的なUnix/Linuxシステム管理に関する情報源（ulimit、リソース制限に関する解説）