古いシステムでは、 \fBsetrlimit\fP() と同様の目的を持つ関数 \fBvlimit\fP() が提供されていた。 後方互換性のため、glibc
でも \fBvlimit\fP() を提供している。 全ての新しいアプリケーションでは、 \fBsetrlimit\fP() を使用すべきである。
.SS "C ライブラリとカーネル ABI の違い"
-Since version 2.13, the glibc \fBgetrlimit\fP() and \fBsetrlimit\fP() wrapper
-functions no longer invoke the corresponding system calls, but instead
-employ \fBprlimit\fP(), for the reasons described in BUGS.
+バージョン 2.13 以降では、 glibc の \fBgetrlimit\fP() と \fBsetrlimit\fP()
+のラッパー関数はもはや対応するシステムコールを呼び出さず、 代わりに「バグ」の節で説明されている理由から \fBprlimit\fP() を利用している。
.SH バグ
以前の Linux カーネルでは、プロセスがソフトまたはハード \fBRLIMIT_CPU\fP リミットに達した場合に送られる \fBSIGXCPU\fP と
\fBSIGKILL\fP シグナルが、本来送られるべき時点の 1 (CPU) 秒後に送られてしまう。 これはカーネル 2.6.8 で修正された。
.\"
2.4.22 より前のカーネルでは、 \fIrlim\->rlim_cur\fP が \fIrlim\->rlim_max\fP より大きかった場合、
\fBsetrlimit\fP() での \fBEINVAL\fP エラーを検出できない。
-.SS "Representation of \(dqlarge\(dq resource limit values on 32\-bit platforms"
+.SS "32 ビットプラットフォームにおける「大きな」リソース上限値の表現"
.\" https://bugzilla.kernel.org/show_bug.cgi?id=5042
.\" http://sources.redhat.com/bugzilla/show_bug.cgi?id=12201
-The glibc \fBgetrlimit\fP() and \fBsetrlimit\fP() wrapper functions use a 64\-bit
-\fIrlim_t\fP data type, even on 32\-bit platforms. However, the \fIrlim_t\fP data
-type used in the \fBgetrlimit\fP() and \fBsetrlimit\fP() system calls is a
-(32\-bit) \fIunsigned long\fP. Furthermore, in Linux versions before 2.6.36,
-the kernel represents resource limits on 32\-bit platforms as \fIunsigned
-long\fP. However, a 32\-bit data type is not wide enough. The most pertinent
-limit here is \fBRLIMIT_FSIZE\fP, which specifies the maximum size to which a
-file can grow: to be useful, this limit must be represented using a type
-that is as wide as the type used to represent file offsets\(emthat is, as
-wide as a 64\-bit \fBoff_t\fP (assuming a program compiled with
-\fI_FILE_OFFSET_BITS=64\fP).
-
-To work around this kernel limitation, if a program tried to set a resource
-limit to a value larger than can be represented in a 32\-bit \fIunsigned
-long\fP, then the glibc \fBsetrlimit\fP() wrapper function silently converted
-the limit value to \fBRLIM_INFINITY\fP. In other words, the requested resource
-limit setting was silently ignored.
-
-This problem was addressed in Linux 2.6.36 with two principal changes:
+glibc の \fBgetrlimit\fP() と \fBsetrlimit\fP() ラッパー関数は、32 ビットプラットフォームであっても 64 ビットの
+\fIrlim_t\fP データ型を使用する。 しかし、 \fBgetrlimit\fP() と \fBsetrlimit\fP() システムコールで使用される
+\fIrlim_t\fP データ型は (32 ビットの) \fIunsigned long\fP である。 さらに、 2.6.36 より前の Linux では、
+カーネルは 32 ビットプラットフォームではリソース上限を \fIunsigned long\fP として表現している。 しかしながら、 32
+ビットデータ型は十分な大きさではない。 ここで最も関係がある上限値は \fBRLIMIT_FSIZE\fP である。
+この上限はファイルサイズの最大値であり、実用性の面からは、 この上限をファイルオフセットを表現するのに使用されている型、 つまり 64 ビットの
+\fBoff_t\fP (\fI_FILE_OFFSET_BITS=64\fP でコンパイルしたプログラムの場合)、 と同じ幅を持つ型、を使って表現すべきである。
+
+カーネルのこの制限に対する対策として、 プログラムがリソース上限を 32 ビットの \fIunsigned long\fP
+で表現できる値よりも大きな値に設定しようとした際には、 glibc の \fBsetrlimit\fP() ラッパー関数はこの上限値を黙って
+\fBRLIM_INFINITY\fP に変換していた。 言い換えると、指定されたリソース上限値は黙って無視されていた。
+
+この問題は Linux 2.6.36 での以下の主な変更により解決された。
.IP * 3
-the addition of a new kernel representation of resource limits that uses 64
-bits, even on 32\-bit platforms;
+32 ビットプラットフォームであっても 64 ビットを使用するリソース上限の新しいカーネルでの表現方法の追加。
.IP *
-the addition of the \fBprlimit\fP() system call, which employs 64\-bit values
-for its resource limit arguments.
+リソース上限の引き数として 64 ビット値を取る \fBprlimit\fP() システムコールの追加。
.PP
.\" https://www.sourceware.org/bugzilla/show_bug.cgi?id=12201
-Since version 2.13, glibc works around the limitations of the \fBgetrlimit\fP()
-and \fBsetrlimit\fP() system calls by implementing \fBsetrlimit\fP() and
-\fBgetrlimit\fP() as wrapper functions that call \fBprlimit\fP().
+バージョン 2.13 以降の glibc では、 \fBgetrlimit\fP() と \fBsetrlimit\fP()
+システムコールの制限に対する回避手段として、
+\fBsetrlimit\fP() と \fBgetrlimit\fP() を \fBprlimit\fP() を呼び出すラッパー関数として実装している。
.SH 例
以下のプログラムに \fBprlimit\fP() の使用例を示す。
.PP
--- /dev/null
+.\" Copyright (c) 2013 by Michael Kerrisk <mtk.manpages@gmail.com>
+.\" and Copyright (c) 2012 by Eric W. Biederman <ebiederm@xmission.com>
+.\"
+.\" %%%LICENSE_START(VERBATIM)
+.\" Permission is granted to make and distribute verbatim copies of this
+.\" manual provided the copyright notice and this permission notice are
+.\" preserved on all copies.
+.\"
+.\" Permission is granted to copy and distribute modified versions of this
+.\" manual under the conditions for verbatim copying, provided that the
+.\" entire resulting derived work is distributed under the terms of a
+.\" permission notice identical to this one.
+.\"
+.\" Since the Linux kernel and libraries are constantly changing, this
+.\" manual page may be incorrect or out-of-date. The author(s) assume no
+.\" responsibility for errors or omissions, or for damages resulting from
+.\" the use of the information contained herein. The author(s) may not
+.\" have taken the same level of care in the production of this manual,
+.\" which is licensed free of charge, as they might when working
+.\" professionally.
+.\"
+.\" Formatted or processed versions of this manual, if unaccompanied by
+.\" the source, must acknowledge the copyright and authors of this work.
+.\" %%%LICENSE_END
+.\"
+.\"
+.\"*******************************************************************
+.\"
+.\" This file was generated with po4a. Translate the source file.
+.\"
+.\"*******************************************************************
+.TH PID_NAMESPACES 7 2014\-09\-21 Linux "Linux Programmer's Manual"
+.SH 名前
+pid_namespaces \- Linux PID 名前空間の概要
+.SH 説明
+名前空間の概要については \fBnamespaces\fP(7) を参照。
+
+PID 名前空間はプロセス ID 番号空間を分離する。 これは、異なる PID 名前空間のプロセスは同じ PID を持つことができることを意味する。
+PID 名前空間を使うことで、コンテナー内のプロセス群を中断、再開したり、 コンテナー内のプロセスの PID
+を保持したままコンテナーを新しいホストに移行したりするといった機能をコンテナーが提供することが可能になる。
+
+新しい PID 名前空間の PID は、 独立したシステムであるかのように、 1 から始まる。 \fBfork\fP(2), \fBvfork\fP(2),
+\fBclone\fP(2) を呼び出すと、 その名前空間内で一意な PID でプロセスが生成される。
+
+.\"
+.\" ============================================================
+.\"
+PID 名前空間を使用するには、設定 \fBCONFIG_PID_NS\fP が有効になったカーネルが必要である。
+.SS "名前空間の init プロセス"
+新しい名前空間で作成される最初のプロセス (すなわち、\fBCLONE_NEWPID\fP フラグで \fBclone\fP(2) を使って作成されたプロセスや、
+\fBCLONE_NEWPID\fP フラグで \fBunshare\fP(2) を呼び出した後のプロセスによって作成された最初のプロセス) は PID 1
+を持ち、 そのプロセスはその名前空間の "init" プロセスとなる (\fBinit\fP(1) 参照)。 名前空間内でみなしごになった
+(親プロセスがいなくなった) 子プロセスは、 \fBinit\fP(1) ではなくこのプロセスが親プロセスになる (ただし、 同じ PID
+名前空間内のその子プロセスの先祖が、 \fBprctl\fP(2) の \fBPR_SET_CHILD_SUBREAPER\fP コマンドを使って、
+自分自身をみなしごとなった子孫のプロセスの引き取り手になっている場合はこの限りではなく)。
+
+PID 名前空間の "init" プロセスが終了すると、 カーネルはその名前空間の全プロセスを \fBSIGKILL\fP シグナルで終了する。 この動作は、
+PID 名前空間の正しい操作のためには "init" プロセスは不可欠であるという事実を反映したものである。 この場合、 その PID
+名前空間へのそれ以降の \fBfork\fP(2) はエラー \fBENOMEM\fP で失敗する。 "init" プロセスが終了している PID
+名前空間に新しいプロセスを作成することはできない。 このような状況は、 例えば、 名前空間にいたプロセスに対応する
+\fI/proc/[pid]/ns/pid\fP ファイルに対してオープンしたファイルディスクリプタを使って、 "init"
+プロセスが終了した後にその名前空間に \fBsetns\fP(2) を行った場合に起こり得る。 \fBunshare\fP(2)
+を呼び出した後にも、この状況は起こり得る。 それ以降に \fBfork\fP(2) で作成された最初の子プロセスが終了すると、 それ以降の
+\fBfork\fP(2) の呼び出しは \fBNOMEM\fP で失敗する。
+
+PID 名前空間の他のメンバーは、 "init" プロセスがシグナルハンドラーを設定したシグナルだけを、 "init" プロセスに送信することができる。
+この制限は特権プロセスに対しても適用される。 この制限により、 PID 名前空間の他のメンバーがうっかり "init"
+プロセスを殺してしまうのを防ぐことができる。
+
+同様に、 先祖の名前空間のプロセスは、 "init" プロセスがそのシグナルに対するハンドラーを設定している場合にのみ、 \fBkill\fP(2)
+で説明されている通常のアクセス許可のチェックを経た上で、 子供の PID 名前空間の "init" プロセスにシグナルを送信できる。
+(ハンドラー内では、 \fIsigaction\fP(2) に説明がある \fIsiginfo_t\fP の \fIsi_pid\fP フィールドは 0 になる。)
+\fBSIGKILL\fP と \fBSIGSTOP\fP は例外として扱われ、 これらのシグナルが先祖の PID
+名前空間から送信された場合には強制的に配送される。 これらのシグナルはどちらも "init" プロセルが捕捉することはできない。
+そのため、これらのシグナルに関連付けられた通常のアクション (それぞれ、プロセスの終了とプロセスの強制停止) が実行される。
+
+.\"
+.\" ============================================================
+.\"
+Linux 3.4 以降では、 \fBreboot\fP(2) システムコールを呼び出すと、 シグナルがその名前空間の "init" プロセスに送信される。
+詳細は \fBreboot\fP(2) を参照。
+.SS "ネストされた PID 名前空間"
+PID 名前空間は入れ子にすることができる。 最初の ("root") PID 名前空間以外の各 PID 名前空間は親を持つ。 PID 名前空間の親は
+\fBclone\fP(2) や \fBunshare\fP(2) を使ってその名前空間を作成したプロセスの PID 名前空間である。 したがって、 PID
+名前空間は木構造を構成し、 すべての名前空間は親を辿って行くと、最終的には root 名前空間に辿り着く。
+
+プロセスは、所属する PID 名前空間の他のプロセスから見える。また、 root PID 名前空間に向かう直径の先祖の各 PID
+名前空間のプロセスからも見える。 この場合、「見える」とは、 あるプロセスが、 他のプロセスがプロセス ID
+を指定するシステムコールを使う際に操作の対象にできることを意味する。 逆に、子供 PID 名前空間のプロセスから親や先祖の名前空間のプロセスは見えない。
+あるプロセスは自分自身の PID 名前空間とその子孫の名前空間のプロセスだけが見える (例えば、\fBkill\fP(2) でシグナルを送信したり、
+\fBsetpriority\fP(2) で nice 値を設定したり、など)。
+
+プロセスは、そのプロセスが見える PID 名前空間の階層の各層においてプロセス ID を一つ持ち、 直接の先祖の名前空間を辿ることで通って root
+PID 名前空間に至ることができる。 プロセス ID に対して操作を行うシステムコールは、常に、呼び出し元プロセスの PID 名前空間で見えるプロセス
+ID を使って操作を行う。 \fBgetpid\fP(2) の呼び出しでは、 常に、 プロセスが作成された名前空間に関連付けられた PID を返す。
+
+.\"
+.\" ============================================================
+.\"
+PID 名前空間内のプロセスは名前空間の外部に親プロセスを持つことができる。 例えば、その名前空間の初期プロセス (すなわち PID 1 を持つ
+\fBinit\fP(1) プロセス) の親プロセスは必然的に別の名前空間に属すことになる。 同様に、 あるプロセスが \fBsetns\fP(2)
+を使って子プロセスを PID 名前空間に参加させた場合、 子プロセスは \fBsetns\fP(2) の呼び出し元とは異なる PID 名前空間に属す。
+子プロセスで \fBgetppid\fP(2) を呼び出すと 0 が返される。
+.SS "setns(2) と unshare(2) の動作"
+PID 名前空間のファイルディスクリプタを指定して \fBsetns\fP(2) を呼び出したり、 \fBCLONE_NEWPID\fP フラグ付きで
+\fBunshare\fP(2) を呼び出したりすると、 その結果作成された子プロセスは呼び出し元とは異なる PID 名前空間に置かれる。
+しかし、これらの呼び出しでは呼び出し元プロセスの PID 名前空間は変更されない。 なぜなら、PID 名前空間を変更してしまうと、 呼び出し元が認識する
+(\fBgetpid\fP() が返す) 自分の PID が変わってしまい、 多くのアプリケーションやライブラリが正しく動作しなくなるからである。
+
+別の言い方をすると、 あるプロセスがどの PID 名前空間に所属するかは、 そのプロセスが作成されたときに決定され、 それ以降は変更されることはない。
+いろいろあるが、プロセス間の親子関係には、PID 名前空間の親子関係がそのまま反映されるということだ。
+プロセスの親プロセスは、同じ名前空間にいるか、もしくは直接の親 PID 名前空間にいるかのいずれかである。
+.SS "CLONE_NEWPID の他の CLONE_* フラグとの互換性"
+\fBCLONE_NEWPID\fP はいくつかの他の \fBCLONE_*\fP フラグと組み合わせることができない。
+.IP * 3
+\fBCLONE_THREAD\fP は、 プロセス内のスレッド間で互いにシグナルを送信できるようにするため、 同じ PID 名前空間に属している必要がある。
+同様に、 プロセス内の全スレッドが \fBproc\fP(5) ファイルシステムで見える必要がある。
+.IP *
+\fBCLONE_SIGHAND\fP は、同じ PID 名前空間である必要がある。 さもなければ、
+シグナルが送信された際に、シグナルを送信したプロセスのプロセス ID を意味のある形でエンコードすることができない (\fBsigaction\fP(2) の
+\fIsiginfo_t\fP 型の説明を参照)。 複数の PID 名前空間に属するプロセス間で一つのシグナルキューを共有すると、うまく動かなくなる。
+.IP *
+\fBCLONE_VM\fP は、全スレッドが同じ PID 名前空間に属している必要がある。 なぜなら、 コアダンプの観点から見ると、 2
+つのプロセスが同じアドレス空間を共有していれば、 これらはスレッドであり、コアダンプが一緒に行われるからである。 コアダンプが書き込まれる際に、
+各スレッドの PID がコアダンプに書き込まれる。 もしプロセス ID のいくつかが親 PID 名前空間に属していたとすると、 プロセス ID
+の書き込みは意味を持たなくなってしまう。
+.PP
+まとめると、 \fBCLONE_THREAD\fP, \fBCLONE_SIGHAND\fP, \fBCLONE_VM\fP では技術的な要件として PID
+名前空間が共有されている点がある。 (さらに \fBclone\fP(2) では \fBCLONE_THREAD\fP か \fBCLONE_SIGHAND\fP
+が指定された際には \fBCLONE_VM\fP が指定されている必要がある点にも注意。) したがって、以下のような順序で呼び出しを行うと (エラー
+\fBEINVAL\fP で) 失敗する。
+
+.nf
+ unshare(CLONE_NEWPID);
+ clone(..., CLONE_VM, ...); /* Fails */
+
+ setns(fd, CLONE_NEWPID);
+ clone(..., CLONE_VM, ...); /* Fails */
+
+ clone(..., CLONE_VM, ...);
+ setns(fd, CLONE_NEWPID); /* Fails */
+
+ clone(..., CLONE_VM, ...);
+ unshare(CLONE_NEWPID); /* Fails */
+.fi
+.\"
+.\" ============================================================
+.\"
+.SS "/proc と PID 名前空間"
+\fI/proc\fP ファイルシステムは、\fI/proc\fP のマウントを行ったプロセスの PID 名前空間で見えるプロセスだけを表示する。 たとえ、 その
+\fI/proc\fP ファイルシステムが他の名前空間のプロセスから参照されたとしても、そうである。
+
+新しい PID 名前空間を作成した後、 子プロセスが、自身の root ディレクトリを変更し、新しい procfs インスタンスを \fI/proc\fP
+にマウントするのは \fBps\fP(1) などのツールが正しく動作するためにも有用である。 \fBclone\fP(2) の \fIflags\fP 引き数に
+\fBCLONE_NEWNS\fP も指定されて新しいマウント名前空間が同時に作成された場合は、 root ディレクトリを変更する必要はない。 新しい
+procfs インスタンスを \fI/proc\fP にそのままマウントすることができる。
+
+シェルから、コマンドで \fI/proc\fP のマウントを行うには次のようにする。
+
+ $ mount \-t proc proc /proc
+
+.\"
+.\" ============================================================
+.\"
+パス \fI/proc/self\fP に対して \fBreadlink\fP(2) を呼び出すと、 procfs のマウントを行ったプロセスの PID
+名前空間におけるプロセス ID が得られる。 これは調査目的でプロセスが他の名前空間で自身の PID を知りたい場合などに役立つ。
+.SS その他
+プロセス ID が UNIX ドメインソケット経由で別の PID 名前空間のプロセスに渡される場合 (\fBunix\fP(7) の
+\fBSCM_CREDENTIALS\fP の説明を参照)、 プロセス ID は受信プロセスの PID 名前空間での対応する PID 値に翻訳される。
+.SH 準拠
+名前空間は Linux 独自の機能である。
+.SH 例
+\fBuser_namespaces\fP(7) 参照。
+.SH 関連項目
+\fBclone\fP(2), \fBsetns\fP(2), \fBunshare\fP(2), \fBproc\fP(5), \fBcredentials\fP(7),
+\fBcapabilities\fP(7), \fBuser_namespaces\fP(7), \fBswitch_root\fP(8)
+.SH この文書について
+この man ページは Linux \fIman\-pages\fP プロジェクトのリリース 3.76 の一部
+である。プロジェクトの説明とバグ報告に関する情報は
+http://www.kernel.org/doc/man\-pages/ に書かれている。
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"POT-Creation-Date: 2015-01-06 03:03+0900\n"
-"PO-Revision-Date: 2015-01-06 14:37+0900\n"
+"PO-Revision-Date: 2015-01-09 05:59+0900\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"Language: \n"
"Since version 2.13, the glibc B<getrlimit>() and B<setrlimit>() wrapper "
"functions no longer invoke the corresponding system calls, but instead "
"employ B<prlimit>(), for the reasons described in BUGS."
-msgstr ""
+msgstr "バージョン 2.13 以降では、 glibc の B<getrlimit>() と B<setrlimit>() のラッパー関数はもはや対応するシステムコールを呼び出さず、 代わりに「バグ」の節で説明されている理由から B<prlimit>() を利用している。"
#. type: Plain text
#: build/C/man2/getrlimit.2:579
#: build/C/man2/getrlimit.2:640
#, no-wrap
msgid "Representation of \"large\" resource limit values on 32-bit platforms"
-msgstr ""
+msgstr "32 ビットプラットフォームにおける「大きな」リソース上限値の表現"
#. https://bugzilla.kernel.org/show_bug.cgi?id=5042
#. http://sources.redhat.com/bugzilla/show_bug.cgi?id=12201
"can grow: to be useful, this limit must be represented using a type that is "
"as wide as the type used to represent file offsets\\(emthat is, as wide as a "
"64-bit B<off_t> (assuming a program compiled with I<_FILE_OFFSET_BITS=64>)."
-msgstr ""
+msgstr "glibc の B<getrlimit>() と B<setrlimit>() ラッパー関数は、32 ビットプラットフォームであっても 64 ビットの I<rlim_t> データ型を使用する。 しかし、 B<getrlimit>() と B<setrlimit>() システムコールで使用される I<rlim_t> データ型は (32 ビットの) I<unsigned long> である。 さらに、 2.6.36 より前の Linux では、 カーネルは 32 ビットプラットフォームではリソース上限を I<unsigned long> として表現している。 しかしながら、 32 ビットデータ型は十分な大きさではない。 ここで最も関係がある上限値は B<RLIMIT_FSIZE> である。 この上限はファイルサイズの最大値であり、実用性の面からは、 この上限をファイルオフセットを表現するのに使用されている型、 つまり 64 ビットの B<off_t> (I<_FILE_OFFSET_BITS=64> でコンパイルしたプログラムの場合)、 と同じ幅を持つ型、を使って表現すべきである。"
#. type: Plain text
#: build/C/man2/getrlimit.2:681
"long>, then the glibc B<setrlimit>() wrapper function silently converted "
"the limit value to B<RLIM_INFINITY>. In other words, the requested resource "
"limit setting was silently ignored."
-msgstr ""
+msgstr "カーネルのこの制限に対する対策として、 プログラムがリソース上限を 32 ビットの I<unsigned long> で表現できる値よりも大きな値に設定しようとした際には、 glibc の B<setrlimit>() ラッパー関数はこの上限値を黙って B<RLIM_INFINITY> に変換していた。 言い換えると、指定されたリソース上限値は黙って無視されていた。"
#. type: Plain text
#: build/C/man2/getrlimit.2:683
msgid "This problem was addressed in Linux 2.6.36 with two principal changes:"
-msgstr ""
+msgstr "この問題は Linux 2.6.36 での以下の主な変更により解決された。"
#. type: Plain text
#: build/C/man2/getrlimit.2:686
msgid ""
"the addition of a new kernel representation of resource limits that uses 64 "
"bits, even on 32-bit platforms;"
-msgstr ""
+msgstr "32 ビットプラットフォームであっても 64 ビットを使用するリソース上限の新しいカーネルでの表現方法の追加。"
#. type: Plain text
#: build/C/man2/getrlimit.2:690
msgid ""
"the addition of the B<prlimit>() system call, which employs 64-bit values "
"for its resource limit arguments."
-msgstr ""
+msgstr "リソース上限の引き数として 64 ビット値を取る B<prlimit>() システムコールの追加。"
#. https://www.sourceware.org/bugzilla/show_bug.cgi?id=12201
#. type: Plain text
"B<setrlimit>() and B<getrlimit>() as wrapper functions that call "
"B<prlimit>()."
msgstr ""
+"バージョン 2.13 以降の glibc では、 B<getrlimit>() と B<setrlimit>() システムコールの制限に対する回避手段として、\n"
+"B<setrlimit>() と B<getrlimit>() を B<prlimit>() を呼び出すラッパー関数として実装している。"
#. type: Plain text
#: build/C/man2/getrlimit.2:706
#. type: Plain text
#: build/C/man7/pid_namespaces.7:33 build/C/man7/user_namespaces.7:33
msgid "For an overview of namespaces, see B<namespaces>(7)."
-msgstr ""
+msgstr "名前空間の概要については B<namespaces>(7) を参照。"
#. type: Plain text
#: build/C/man7/pid_namespaces.7:40
"containers to provide functionality such as suspending/resuming the set of "
"processes in the container and migrating the container to a new host while "
"the processes inside the container maintain the same PIDs."
-msgstr ""
+msgstr "PID 名前空間はプロセス ID 番号空間を分離する。 これは、異なる PID 名前空間のプロセスは同じ PID を持つことができることを意味する。 PID 名前空間を使うことで、コンテナー内のプロセス群を中断、再開したり、 コンテナー内のプロセスの PID を保持したままコンテナーを新しいホストに移行したりするといった機能をコンテナーが提供することが可能になる。"
#. type: Plain text
#: build/C/man7/pid_namespaces.7:48
"PIDs in a new PID namespace start at 1, somewhat like a standalone system, "
"and calls to B<fork>(2), B<vfork>(2), or B<clone>(2) will produce processes "
"with PIDs that are unique within the namespace."
-msgstr ""
+msgstr "新しい PID 名前空間の PID は、 独立したシステムであるかのように、 1 から始まる。 B<fork>(2), B<vfork>(2), B<clone>(2) を呼び出すと、 その名前空間内で一意な PID でプロセスが生成される。"
#
#. ============================================================
#: build/C/man7/pid_namespaces.7:55
#, no-wrap
msgid "The namespace init process"
-msgstr ""
+msgstr "名前空間の init プロセス"
#. type: Plain text
#: build/C/man7/pid_namespaces.7:75
"ancestors of the child in the same PID namespace employed the B<prctl>(2) "
"B<PR_SET_CHILD_SUBREAPER> command to mark itself as the reaper of orphaned "
"descendant processes)."
-msgstr ""
+msgstr "新しい名前空間で作成される最初のプロセス (すなわち、B<CLONE_NEWPID> フラグで B<clone>(2) を使って作成されたプロセスや、 B<CLONE_NEWPID> フラグで B<unshare>(2) を呼び出した後のプロセスによって作成された最初のプロセス) は PID 1 を持ち、 そのプロセスはその名前空間の \"init\" プロセスとなる (B<init>(1) 参照)。 名前空間内でみなしごになった (親プロセスがいなくなった) 子プロセスは、 B<init>(1) ではなくこのプロセスが親プロセスになる (ただし、 同じ PID 名前空間内のその子プロセスの先祖が、 B<prctl>(2) の B<PR_SET_CHILD_SUBREAPER> コマンドを使って、 自分自身をみなしごとなった子孫のプロセスの引き取り手になっている場合はこの限りではなく)。"
#. type: Plain text
#: build/C/man7/pid_namespaces.7:102
"scenario can occur after a call to B<unshare>(2): if the first child "
"subsequently created by a B<fork>(2) terminates, then subsequent calls to "
"B<fork>(2) will fail with B<ENOMEM>."
-msgstr ""
+msgstr "PID 名前空間の \"init\" プロセスが終了すると、 カーネルはその名前空間の全プロセスを B<SIGKILL> シグナルで終了する。 この動作は、 PID 名前空間の正しい操作のためには \"init\" プロセスは不可欠であるという事実を反映したものである。 この場合、 その PID 名前空間へのそれ以降の B<fork>(2) はエラー B<ENOMEM> で失敗する。 \"init\" プロセスが終了している PID 名前空間に新しいプロセスを作成することはできない。 このような状況は、 例えば、 名前空間にいたプロセスに対応する I</proc/[pid]/ns/pid> ファイルに対してオープンしたファイルディスクリプタを使って、 \"init\" プロセスが終了した後にその名前空間に B<setns>(2) を行った場合に起こり得る。 B<unshare>(2) を呼び出した後にも、この状況は起こり得る。 それ以降に B<fork>(2) で作成された最初の子プロセスが終了すると、 それ以降の B<fork>(2) の呼び出しは B<NOMEM> で失敗する。"
#. type: Plain text
#: build/C/man7/pid_namespaces.7:108
"can be sent to the \"init\" process by other members of the PID namespace. "
"This restriction applies even to privileged processes, and prevents other "
"members of the PID namespace from accidentally killing the \"init\" process."
-msgstr ""
+msgstr "PID 名前空間の他のメンバーは、 \"init\" プロセスがシグナルハンドラーを設定したシグナルだけを、 \"init\" プロセスに送信することができる。 この制限は特権プロセスに対しても適用される。 この制限により、 PID 名前空間の他のメンバーがうっかり \"init\" プロセスを殺してしまうのを防ぐことができる。"
#. type: Plain text
#: build/C/man7/pid_namespaces.7:128
"these signals can be caught by the \"init\" process, and so will result in "
"the usual actions associated with those signals (respectively, terminating "
"and stopping the process)."
-msgstr ""
+msgstr "同様に、 先祖の名前空間のプロセスは、 \"init\" プロセスがそのシグナルに対するハンドラーを設定している場合にのみ、 B<kill>(2) で説明されている通常のアクセス許可のチェックを経た上で、 子供の PID 名前空間の \"init\" プロセスにシグナルを送信できる。 (ハンドラー内では、 I<sigaction>(2) に説明がある I<siginfo_t> の I<si_pid> フィールドは 0 になる。) B<SIGKILL> と B<SIGSTOP> は例外として扱われ、 これらのシグナルが先祖の PID 名前空間から送信された場合には強制的に配送される。 これらのシグナルはどちらも \"init\" プロセルが捕捉することはできない。 そのため、これらのシグナルに関連付けられた通常のアクション (それぞれ、プロセスの終了とプロセスの強制停止) が実行される。"
#
#. ============================================================
msgid ""
"Starting with Linux 3.4, the B<reboot>(2) system call causes a signal to be "
"sent to the namespace \"init\" process. See B<reboot>(2) for more details."
-msgstr ""
+msgstr "Linux 3.4 以降では、 B<reboot>(2) システムコールを呼び出すと、 シグナルがその名前空間の \"init\" プロセスに送信される。 詳細は B<reboot>(2) を参照。"
#. type: SS
#: build/C/man7/pid_namespaces.7:138
#, no-wrap
msgid "Nesting PID namespaces"
-msgstr ""
+msgstr "ネストされた PID 名前空間"
#. type: Plain text
#: build/C/man7/pid_namespaces.7:149
"PID namespace of the process that created the namespace using B<clone>(2) "
"or B<unshare>(2). PID namespaces thus form a tree, with all namespaces "
"ultimately tracing their ancestry to the root namespace."
-msgstr ""
+msgstr "PID 名前空間は入れ子にすることができる。 最初の (\"root\") PID 名前空間以外の各 PID 名前空間は親を持つ。 PID 名前空間の親は B<clone>(2) や B<unshare>(2) を使ってその名前空間を作成したプロセスの PID 名前空間である。 したがって、 PID 名前空間は木構造を構成し、 すべての名前空間は親を辿って行くと、最終的には root 名前空間に辿り着く。"
#. type: Plain text
#: build/C/man7/pid_namespaces.7:164
"succinctly: a process can see (e.g., send signals with B<kill>(2), set nice "
"values with B<setpriority>(2), etc.) only processes contained in its own PID "
"namespace and in descendants of that namespace."
-msgstr ""
+msgstr "プロセスは、所属する PID 名前空間の他のプロセスから見える。また、 root PID 名前空間に向かう直径の先祖の各 PID 名前空間のプロセスからも見える。 この場合、「見える」とは、 あるプロセスが、 他のプロセスがプロセス ID を指定するシステムコールを使う際に操作の対象にできることを意味する。 逆に、子供 PID 名前空間のプロセスから親や先祖の名前空間のプロセスは見えない。 あるプロセスは自分自身の PID 名前空間とその子孫の名前空間のプロセスだけが見える (例えば、B<kill>(2) でシグナルを送信したり、 B<setpriority>(2) で nice 値を設定したり、など)。"
#. type: Plain text
#: build/C/man7/pid_namespaces.7:176
"process IDs always operate using the process ID that is visible in the PID "
"namespace of the caller. A call to B<getpid>(2) always returns the PID "
"associated with the namespace in which the process was created."
-msgstr ""
+msgstr "プロセスは、そのプロセスが見える PID 名前空間の階層の各層においてプロセス ID を一つ持ち、 直接の先祖の名前空間を辿ることで通って root PID 名前空間に至ることができる。 プロセス ID に対して操作を行うシステムコールは、常に、呼び出し元プロセスの PID 名前空間で見えるプロセス ID を使って操作を行う。 B<getpid>(2) の呼び出しでは、 常に、 プロセスが作成された名前空間に関連付けられた PID を返す。"
#
#. ============================================================
"B<setns>(2) to cause its children to join a PID namespace are in a "
"different PID namespace from the caller of B<setns>(2). Calls to "
"B<getppid>(2) for such processes return 0."
-msgstr ""
+msgstr "PID 名前空間内のプロセスは名前空間の外部に親プロセスを持つことができる。 例えば、その名前空間の初期プロセス (すなわち PID 1 を持つ B<init>(1) プロセス) の親プロセスは必然的に別の名前空間に属すことになる。 同様に、 あるプロセスが B<setns>(2) を使って子プロセスを PID 名前空間に参加させた場合、 子プロセスは B<setns>(2) の呼び出し元とは異なる PID 名前空間に属す。 子プロセスで B<getppid>(2) を呼び出すと 0 が返される。"
#. type: SS
#: build/C/man7/pid_namespaces.7:194
#, no-wrap
msgid "setns(2) and unshare(2) semantics"
-msgstr ""
+msgstr "setns(2) と unshare(2) の動作"
#. type: Plain text
#: build/C/man7/pid_namespaces.7:210
"calling process, because doing so would change the caller's idea of its own "
"PID (as reported by B<getpid>()), which would break many applications and "
"libraries."
-msgstr ""
+msgstr "PID 名前空間のファイルディスクリプタを指定して B<setns>(2) を呼び出したり、 B<CLONE_NEWPID> フラグ付きで B<unshare>(2) を呼び出したりすると、 その結果作成された子プロセスは呼び出し元とは異なる PID 名前空間に置かれる。 しかし、これらの呼び出しでは呼び出し元プロセスの PID 名前空間は変更されない。 なぜなら、PID 名前空間を変更してしまうと、 呼び出し元が認識する (B<getpid>() が返す) 自分の PID が変わってしまい、 多くのアプリケーションやライブラリが正しく動作しなくなるからである。"
#. type: Plain text
#: build/C/man7/pid_namespaces.7:218
"processes mirrors the parental relationship between PID namespaces: the "
"parent of a process is either in the same namespace or resides in the "
"immediate parent PID namespace."
-msgstr ""
+msgstr "別の言い方をすると、 あるプロセスがどの PID 名前空間に所属するかは、 そのプロセスが作成されたときに決定され、 それ以降は変更されることはない。 いろいろあるが、プロセス間の親子関係には、PID 名前空間の親子関係がそのまま反映されるということだ。 プロセスの親プロセスは、同じ名前空間にいるか、もしくは直接の親 PID 名前空間にいるかのいずれかである。"
#. type: SS
#: build/C/man7/pid_namespaces.7:218
#, no-wrap
msgid "Compatibility of CLONE_NEWPID with other CLONE_* flags"
-msgstr ""
+msgstr "CLONE_NEWPID の他の CLONE_* フラグとの互換性"
#. type: Plain text
#: build/C/man7/pid_namespaces.7:223
msgid "B<CLONE_NEWPID> can't be combined with some other B<CLONE_*> flags:"
-msgstr ""
+msgstr "B<CLONE_NEWPID> はいくつかの他の B<CLONE_*> フラグと組み合わせることができない。"
#. type: Plain text
#: build/C/man7/pid_namespaces.7:231
"the threads in a process can send signals to each other. Similarly, it must "
"be possible to see all of the threads of a processes in the B<proc>(5) "
"filesystem."
-msgstr ""
+msgstr "B<CLONE_THREAD> は、 プロセス内のスレッド間で互いにシグナルを送信できるようにするため、 同じ PID 名前空間に属している必要がある。 同様に、 プロセス内の全スレッドが B<proc>(5) ファイルシステムで見える必要がある。"
#. type: Plain text
#: build/C/man7/pid_namespaces.7:242
"when a signal is sent (see the description of the I<siginfo_t> type in "
"B<sigaction>(2)). A signal queue shared by processes in multiple PID "
"namespaces will defeat that."
-msgstr ""
+msgstr "B<CLONE_SIGHAND> は、同じ PID 名前空間である必要がある。 さもなければ、 シグナルが送信された際に、シグナルを送信したプロセスのプロセス ID を意味のある形でエンコードすることができない (B<sigaction>(2) の I<siginfo_t> 型の説明を参照)。 複数の PID 名前空間に属するプロセス間で一つのシグナルキューを共有すると、うまく動かなくなる。"
#. type: Plain text
#: build/C/man7/pid_namespaces.7:252
"When a core dump is written, the PID of each thread is written into the core "
"dump. Writing the process IDs could not meaningfully succeed if some of the "
"process IDs were in a parent PID namespace."
-msgstr ""
+msgstr "B<CLONE_VM> は、全スレッドが同じ PID 名前空間に属している必要がある。 なぜなら、 コアダンプの観点から見ると、 2 つのプロセスが同じアドレス空間を共有していれば、 これらはスレッドであり、コアダンプが一緒に行われるからである。 コアダンプが書き込まれる際に、 各スレッドの PID がコアダンプに書き込まれる。 もしプロセス ID のいくつかが親 PID 名前空間に属していたとすると、 プロセス ID の書き込みは意味を持たなくなってしまう。"
#. type: Plain text
#: build/C/man7/pid_namespaces.7:270
"furthermore that in B<clone>(2) requires B<CLONE_VM> to be specified if "
"B<CLONE_THREAD> or B<CLONE_SIGHAND> is specified.) Thus, call sequences "
"such as the following will fail (with the error B<EINVAL>):"
-msgstr ""
+msgstr "まとめると、 B<CLONE_THREAD>, B<CLONE_SIGHAND>, B<CLONE_VM> では技術的な要件として PID 名前空間が共有されている点がある。 (さらに B<clone>(2) では B<CLONE_THREAD> か B<CLONE_SIGHAND> が指定された際には B<CLONE_VM> が指定されている必要がある点にも注意。) したがって、以下のような順序で呼び出しを行うと (エラー B<EINVAL> で) 失敗する。"
#. type: Plain text
#: build/C/man7/pid_namespaces.7:274
"A I</proc> filesystem shows (in the I</proc/PID> directories) only processes "
"visible in the PID namespace of the process that performed the mount, even "
"if the I</proc> filesystem is viewed from processes in other namespaces."
-msgstr ""
+msgstr "I</proc> ファイルシステムは、I</proc> のマウントを行ったプロセスの PID 名前空間で見えるプロセスだけを表示する。 たとえ、 その I</proc> ファイルシステムが他の名前空間のプロセスから参照されたとしても、そうである。"
#. type: Plain text
#: build/C/man7/pid_namespaces.7:315
"simultaneously created by including B<CLONE_NEWNS> in the I<flags> argument "
"of B<clone>(2) or B<unshare>(2), then it isn't necessary to change the root "
"directory: a new procfs instance can be mounted directly over I</proc>."
-msgstr ""
+msgstr "新しい PID 名前空間を作成した後、 子プロセスが、自身の root ディレクトリを変更し、新しい procfs インスタンスを I</proc> にマウントするのは B<ps>(1) などのツールが正しく動作するためにも有用である。 B<clone>(2) の I<flags> 引き数に B<CLONE_NEWNS> も指定されて新しいマウント名前空間が同時に作成された場合は、 root ディレクトリを変更する必要はない。 新しい procfs インスタンスを I</proc> にそのままマウントすることができる。"
#. type: Plain text
#: build/C/man7/pid_namespaces.7:319
msgid "From a shell, the command to mount I</proc> is:"
-msgstr ""
+msgstr "シェルから、コマンドで I</proc> のマウントを行うには次のようにする。"
#. type: Plain text
#: build/C/man7/pid_namespaces.7:321
"of the process that mounted the procfs). This can be useful for "
"introspection purposes, when a process wants to discover its PID in other "
"namespaces."
-msgstr ""
+msgstr "パス I</proc/self> に対して B<readlink>(2) を呼び出すと、 procfs のマウントを行ったプロセスの PID 名前空間におけるプロセス ID が得られる。 これは調査目的でプロセスが他の名前空間で自身の PID を知りたい場合などに役立つ。"
#. type: SS
#: build/C/man7/pid_namespaces.7:333 build/C/man7/user_namespaces.7:635
#, no-wrap
msgid "Miscellaneous"
-msgstr ""
+msgstr "その他"
#. type: Plain text
#: build/C/man7/pid_namespaces.7:341
"different PID namespace (see the description of B<SCM_CREDENTIALS> in "
"B<unix>(7)), it is translated into the corresponding PID value in the "
"receiving process's PID namespace."
-msgstr ""
+msgstr "プロセス ID が UNIX ドメインソケット経由で別の PID 名前空間のプロセスに渡される場合 (B<unix>(7) の B<SCM_CREDENTIALS> の説明を参照)、 プロセス ID は受信プロセスの PID 名前空間での対応する PID 値に翻訳される。"
#. type: Plain text
#: build/C/man7/pid_namespaces.7:355
"The comments and I<usage()> function inside the program provide a full "
"explanation of the program. The following shell session demonstrates its "
"use."
-msgstr ""
+msgstr "以下のプログラムは、ユーザー名前空間で実験を行えるように設計されている。 他の種類の名前空間も扱える。 このプログラムはコマンドライン引き数で指定された名前空間を作成し、作成した名前空間内でコマンドを実行する。 コメントとプログラム内の I<usage()> 関数に、プログラムの詳しい説明が書かれている。 以下のシェルセッションに実行例を示す。"
#. type: Plain text
#: build/C/man7/user_namespaces.7:688
msgid "First, we look at the run-time environment:"
-msgstr ""
+msgstr "まず最初に、実行環境を確認しておく。"
#. type: Plain text
#: build/C/man7/user_namespaces.7:697
"$ B<id -g>\n"
"1000\n"
msgstr ""
-"$ B<uname -rs> # Need Linux 3.8 or later\n"
+"$ B<uname -rs> # Linux 3.8 以降が必要\n"
"Linux 3.8.0\n"
-"$ B<id -u> # Running as unprivileged user\n"
+"$ B<id -u> # 非特権ユーザーで実行する\n"
"1000\n"
"$ B<id -g>\n"
"1000\n"
"Now start a new shell in new user (I<-U>), mount (I<-m>), and PID (I<-p>) "
"namespaces, with user ID (I<-M>) and group ID (I<-G>) 1000 mapped to 0 "
"inside the user namespace:"
-msgstr ""
+msgstr "新しいユーザー名前空間 (I<-U>), マウント名前空間 (I<-m>), PID 名前空間 (I<-p>) で新しいシェルを開始する。ユーザー ID (I<-M>) 1000 とグループ ID (I<-G>) 1000 をユーザー名前空間内で 0 にマッピングしている。"
#. type: Plain text
#: build/C/man7/user_namespaces.7:715
msgid ""
"The shell has PID 1, because it is the first process in the new PID "
"namespace:"
-msgstr ""
+msgstr "シェルは PID 1 を持つ。このシェルは新しい PID 名前空間の最初のプロセスだからである。"
#. type: Plain text
#: build/C/man7/user_namespaces.7:725
msgid ""
"Inside the user namespace, the shell has user and group ID 0, and a full set "
"of permitted and effective capabilities:"
-msgstr ""
+msgstr "ユーザー名前空間内では、シェルのユーザー ID とグループ ID ともに 0 で、すべての許可ケーパビリティと実効ケーパビリティが有効になっている。"
#. type: Plain text
#: build/C/man7/user_namespaces.7:740
"Mounting a new I</proc> filesystem and listing all of the processes visible "
"in the new PID namespace shows that the shell can't see any processes "
"outside the PID namespace:"
-msgstr ""
+msgstr "I</proc> ファイルシステムをマウントし、新しい PID 名前空間で見えるプロセス一覧を表示すると、 シェルからは PID 名前空間外のプロセスが見えないことが分かる。"
#. type: Plain text
#: build/C/man7/user_namespaces.7:756
"#include E<lt>limits.hE<gt>\n"
"#include E<lt>errno.hE<gt>\n"
msgstr ""
+" 新しい名前空間でシェルコマンドを実行する子プロセスを作成する。\n"
+" ユーザー名前空間を作成する際に UID と GID のマッピングを\n"
+" 指定することができる。\n"
+"*/\n"
+"#define _GNU_SOURCE\n"
+"#include E<lt>sched.hE<gt>\n"
+"#include E<lt>unistd.hE<gt>\n"
+"#include E<lt>stdlib.hE<gt>\n"
+"#include E<lt>sys/wait.hE<gt>\n"
+"#include E<lt>signal.hE<gt>\n"
+"#include E<lt>fcntl.hE<gt>\n"
+"#include E<lt>stdio.hE<gt>\n"
+"#include E<lt>string.hE<gt>\n"
+"#include E<lt>limits.hE<gt>\n"
+"#include E<lt>errno.hE<gt>\n"
#. type: Plain text
#: build/C/man7/user_namespaces.7:783
"/* A simple error-handling function: print an error message based\n"
" on the value in \\(aqerrno\\(aq and terminate the calling process */\n"
msgstr ""
-"/* A simple error-handling function: print an error message based\n"
-" on the value in \\(aqerrno\\(aq and terminate the calling process */\n"
+"/* 簡単なエラー処理関数: \\\\(aqerrno\\\\(aq の値に基づいて\n"
+" エラーメッセージを出力し、呼び出し元プロセスを終了する。 */\n"
#. type: Plain text
#: build/C/man7/user_namespaces.7:786
"};\n"
msgstr ""
"struct child_args {\n"
-" char **argv; /* Command to be executed by child, with args */\n"
-" int pipe_fd[2]; /* Pipe used to synchronize parent and child */\n"
+" char **argv; /* 子プロセスが実行するコマンドと引き数 */\n"
+" int pipe_fd[2]; /* 親プロセスと子プロセスを同期するためのパイプ */\n"
"};\n"
#. type: Plain text
#: build/C/man7/user_namespaces.7:892
#, no-wrap
msgid " /* Execute a shell command */\n"
-msgstr ""
+msgstr " /* シェルコマンドを実行する */\n"
#. type: Plain text
#: build/C/man7/user_namespaces.7:897
#: build/C/man7/user_namespaces.7:901
#, no-wrap
msgid "static char child_stack[STACK_SIZE]; /* Space for child\\(aqs stack */\n"
-msgstr ""
+msgstr "static char child_stack[STACK_SIZE]; /* 子プロセスのスタック空間 */\n"
#. type: Plain text
#: build/C/man7/user_namespaces.7:912
#: build/C/man7/user_namespaces.7:942
#, no-wrap
msgid " /* -M or -G without -U is nonsensical */\n"
-msgstr ""
+msgstr " /* -U なしの -M や -G の指定は意味がない */\n"
#. type: Plain text
#: build/C/man7/user_namespaces.7:947
#: build/C/man7/user_namespaces.7:964
#, no-wrap
msgid " /* Create the child in new namespace(s) */\n"
-msgstr ""
+msgstr " /* 新しい名前空間で子プロセスを作成する */\n"
#. type: Plain text
#: build/C/man7/user_namespaces.7:969
#: build/C/man7/user_namespaces.7:971
#, no-wrap
msgid " /* Parent falls through to here */\n"
-msgstr ""
+msgstr " /* 親プロセスはここを実行する */\n"
#. type: Plain text
#: build/C/man7/user_namespaces.7:975
#: build/C/man7/user_namespaces.7:977
#, no-wrap
msgid " /* Update the UID and GID maps in the child */\n"
-msgstr ""
+msgstr " /* 子プロセスの UID と GID のマッピングを更新する */\n"
#. type: Plain text
#: build/C/man7/user_namespaces.7:996
" /* Close the write end of the pipe, to signal to the child that we\n"
" have updated the UID and GID maps */\n"
msgstr ""
+" /* パイプの書き込み端をクローズし、子プロセスに UID と GID の\n"
+" マッピングが更新されたことを知らせる */\n"
#. type: Plain text
#: build/C/man7/user_namespaces.7:1001
" if (waitpid(child_pid, NULL, 0) == -1) /* Wait for child */\n"
" errExit(\"waitpid\");\n"
msgstr ""
-" if (waitpid(child_pid, NULL, 0) == -1) /* Wait for child */\n"
+" if (waitpid(child_pid, NULL, 0) == -1) /* 子プロセスを待つ */\n"
" errExit(\"waitpid\");\n"
#. type: Plain text
OSDN Git Service
