.\" to deal with the CLOCK_PROCESS_CPUTIME_ID case.
そのプロセスの全スレッドで消費される CPU 時間を計測するプロセス単位の クロック。このクロックは設定可能である。
.PP
-See \fBclock_getres\fP(2) for further details on these clocks. In addition,
-the CPU clock IDs returned by \fBclock_getcpuclockid\fP(3) and
-\fBpthread_getcpuclockid\fP(3) can also be passed in \fIclock_id\fP.
+これらのクロックの詳細は \fBclock_getres\fP(2) を参照。 また、 \fBclock_getcpuclockid\fP(3) と
+\fBpthread_getcpuclockid\fP(3) が返す CPU クロック ID は \fIclock_id\fP に渡すこともできる。
\fIflags\fP が 0 の場合、 \fIrequest\fP に指定された値は \fIclock_id\fP
で指定されたクロックの現在の値からの相対的な期間と解釈される。
IPC 名前空間が破棄される時 (すなわち、その名前空間のメンバーの最後のプロセスが終了する時)、 その名前空間の全ての IPC
オブジェクトは自動的に破棄される。
-Only a privileged process (\fBCAP_SYS_ADMIN\fP) can employ \fBCLONE_NEWIPC\fP.
-This flag can't be specified in conjunction with \fBCLONE_SYSVSEM\fP.
+特権プロセス (\fBCAP_SYS_ADMIN\fP) だけが \fBCLONE_NEWIPC\fP を使用できる。 このフラグは
+\fBCLONE_SYSVSEM\fP と組み合わせて指定することはできない。
-For further information on IPC namespaces, see \fBnamespaces\fP(7).
+IPC 名前空間の詳細は \fBnamespaces\fP(7) を参照。
.TP
\fBCLONE_NEWNET\fP (Linux 2.6.24 以降)
(このフラグの実装は、Linux 2.6.29 あたりまでには完成した。)
(initial network namespace) に戻される (親プロセスのネットワーク名前空間に戻される訳ではない)。
ネットワーク名前空間のさらなる情報は \fBnamespaces\fP(7) を参照。
-Only a privileged process (\fBCAP_SYS_ADMIN\fP) can employ \fBCLONE_NEWNET\fP.
+特権プロセス (\fBCAP_SYS_ADMIN\fP) だけが \fBCLONE_NEWNET\fP を使用できる。
.TP
\fBCLONE_NEWNS\fP (Linux 2.4.19 以降)
-If \fBCLONE_NEWNS\fP is set, the cloned child is started in a new mount
-namespace, initialized with a copy of the namespace of the parent. If
-\fBCLONE_NEWNS\fP is not set, the child lives in the same mount namespace as
-the parent.
+\fBCLONE_NEWNS\fP がセットされている場合、 clone で作成された子プロセスは新しいマウント名前空間で開始され、
+新しい名前空間は親プロセスの名前空間のコピーで初期化される。 \fBCLONE_NEWNS\fP がセットされていない場合、
+子プロセスは親プロセスと同じマウント名前空間となる。
-For further information on mount namespaces, see \fBnamespaces\fP(7).
+マウント名前空間の詳細は \fBnamespaces\fP(7) を参照。
.\" See https://lwn.net/Articles/543273/
特権プロセス (\fBCAP_SYS_ADMIN\fP) のみが \fBCLONE_NEWNS\fP を指定することができる。 一つの \fBclone\fP()
(\fBfork\fP(2) の場合と同様) 呼び出し元のプロセスと同じ PID 名前空間で プロセスが作成される。
このフラグは、コンテナの実装での使用を意図して用意されたものである。
-For further information on PID namespaces, see \fBnamespaces\fP(7) and
-\fBpid_namespaces\fP(7)
+PID 名前空間の詳細は \fBnamespaces\fP(7) と \fBpid_namespaces\fP(7) を参照。
-Only a privileged process (\fBCAP_SYS_ADMIN\fP) can employ \fBCLONE_NEWPID\fP.
-This flag can't be specified in conjunction with \fBCLONE_THREAD\fP or
-\fBCLONE_PARENT\fP.
+特権プロセス (\fBCAP_SYS_ADMIN\fP) だけが \fBCLONE_NEWPID\fP を使用できる。 このフラグは \fBCLONE_THREAD\fP
+や \fBCLONE_PARENT\fP と組み合わせて指定することはできない。
.TP
\fBCLONE_NEWUSER\fP
-(This flag first became meaningful for \fBclone\fP() in Linux 2.6.23, the
-current \fBclone()\fP semantics were merged in Linux 3.5, and the final pieces
-to make the user namespaces completely usable were merged in Linux 3.8.)
+(このフラグが \fBclone\fP() で意味を持つようになったのは Linux 2.6.23 である。 現在の \fBclone\fP()
+の動作が取り込まれたのは Linux 3.5 であり、 ユーザー名前空間が完全に機能するようにする最後の機能が取り込まれたのは Linux 3.8
+である。)
-If \fBCLONE_NEWUSER\fP is set, then create the process in a new user
-namespace. If this flag is not set, then (as with \fBfork\fP(2)) the process
-is created in the same user namespace as the calling process.
+\fBCLONE_NEWUSER\fP がセットされている場合、新しいユーザー名前空間でプロセスを作成する。 このフラグがセットされていない場合、
+(\fBfork\fP(2) の場合と同様に) 呼び出し元のプロセスと同じユーザー名前空間でプロセスが作成される。
-For further information on user namespaces, see \fBnamespaces\fP(7) and
-\fBuser_namespaces\fP(7)
+ユーザー名前空間の詳細は \fBnamespaces\fP(7) と \fBuser_namespaces\fP(7) を参照。
.\" Before Linux 2.6.29, it appears that only CAP_SYS_ADMIN was needed
-Before Linux 3.8, use of \fBCLONE_NEWUSER\fP required that the caller have
-three capabilities: \fBCAP_SYS_ADMIN\fP, \fBCAP_SETUID\fP, and \fBCAP_SETGID\fP.
-Starting with Linux 3.8, no privileges are needed to create a user
-namespace.
+Linux 3.8 より前では、 \fBCLONE_NEWUSER\fP を使用するには、 呼び出し元は \fBCAP_SYS_ADMIN\fP,
+\fBCAP_SETUID\fP, \fBCAP_SETGID\fP の 3 つのケーパリビティを持っている必要があった。 Linux 3.8 以降では、
+ユーザー名前空間を作成するのに特権は必要なくなった。
.\" commit e66eded8309ebf679d3d3c1f5820d1f2ca332c71
.\" https://lwn.net/Articles/543273/
.\" The fix actually went into 3.9 and into 3.8.3. However, user namespaces
.\" were, for practical purposes, unusable in earlier 3.8.x because of the
.\" various filesystems that didn't support userns.
-This flag can't be specified in conjunction with \fBCLONE_THREAD\fP or
-\fBCLONE_PARENT\fP. For security reasons, \fBCLONE_NEWUSER\fP cannot be specified
-in conjunction with \fBCLONE_FS\fP.
+このフラグは \fBCLONE_THREAD\fP や \fBCLONE_PARENT\fP と組み合わせて指定することはできない。 セキュリティ上の理由から、
+\fBCLONE_NEWUSER\fP は \fBCLONE_FS\fP と組み合わせて指定することはできない。
-For further information on user namespaces, see \fBuser_namespaces\fP(7).
+ユーザー名前空間の詳細は \fBuser_namespaces\fP(7) を参照。
.TP
\fBCLONE_NEWUTS\fP (Linux 2.6.19 以降)
\fBCLONE_NEWUTS\fP が設定された場合、新しい UTS 名前空間でプロセスを作成する。 新しい UTS
\fBsetdomainname\fP(2), \fBsethostname\fP(2) で修正することができる。 ある UTS
名前空間における識別子の変更は同じ名前空間の他のすべての プロセスに見えるが、別の UTS 名前空間のプロセスには見えない。
-Only a privileged process (\fBCAP_SYS_ADMIN\fP) can employ \fBCLONE_NEWUTS\fP.
+特権プロセス (\fBCAP_SYS_ADMIN\fP) だけが \fBCLONE_NEWUTS\fP を使用できる。
-For further information on UTS namespaces, see \fBnamespaces\fP(7).
+UTS 名前空間の詳細は \fBnamespaces\fP(7) を参照。
.TP
\fBCLONE_PARENT\fP (Linux 2.3.12 以降)
\fBCLONE_PARENT\fP が設定された場合、新しい子供の (\fBgetppid\fP(2) で返される)
Linux 2.6.38 で完全に\fI削除\fPされた。
.TP
\fBCLONE_SYSVSEM\fP (Linux 2.5.10 以降)
-If \fBCLONE_SYSVSEM\fP is set, then the child and the calling process share a
-single list of System V semaphore adjustment (\fIsemadj\fP) values (see
-\fBsemop\fP(2)). In this case, the shared list accumulates \fIsemadj\fP values
-across all processes sharing the list, and semaphore adjustments are
-performed only when the last process that is sharing the list terminates (or
-ceases sharing the list using \fBunshare\fP(2)). If this flag is not set, then
-the child has a separate \fIsemadj\fP list that is initially empty.
+\fBCLONE_SYSVSEM\fP がセットされると、子プロセスと呼び出し元プロセスは一つの System\ V セマフォの調整値 (\fIsemadj\fP)
+(\fBsemop\fP(2) 参照) を共有する。 この場合、共有されたリストはこのリストを共有する全プロセスの \fIsemadj\fP 値を積算し、
+セマフォ調整はこのリストを共有している最後のプロセスが終了した際 (または \fBunshare\fP(2) を使ってリストの共有が中止された際)
+に実行される。 このフラグがセットされていなければ、 子プロセスは独自のセマフォ \fIsemadj\fP リストを持つ (リストの初期値は空である)。
.TP
\fBCLONE_THREAD\fP (Linux 2.4.0\-test8以降)
\fBCLONE_THREAD\fP が設定された場合、子プロセスは呼び出し元のプロセスと同じスレッドグループに 置かれる。 \fBCLONE_THREAD\fP
\fBCLONE_NEWIPC\fP と \fBCLONE_SYSVSEM\fP の両方が \fIflags\fP に指定された。
.TP
\fBEINVAL\fP
-One (or both) of \fBCLONE_NEWPID\fP or \fBCLONE_NEWUSER\fP and one (or both) of
-\fBCLONE_THREAD\fP or \fBCLONE_PARENT\fP were specified in \fIflags\fP.
+\fBCLONE_NEWPID\fP と \fBCLONE_NEWUSER\fP の一方 (もしくは両方) と、 \fBCLONE_THREAD\fP と
+\fBCLONE_PARENT\fP の一方 (もしくは両方) が、 \fIflags\fP に指定された。
.TP
\fBEINVAL\fP
\fIchild_stack\fP にゼロを指定した場合に \fBclone\fP() が返す。
PID が 0 以外のプロセスによって \fBCLONE_PID\fP が指定された。
.TP
\fBEPERM\fP
-\fBCLONE_NEWUSER\fP was specified in \fIflags\fP, but either the effective user ID
-or the effective group ID of the caller does not have a mapping in the
-parent namespace (see \fBuser_namespaces\fP(7)).
+\fBCLONE_NEWUSER\fP が \fIflags\fP に指定されたが、 呼び出し元の実効ユーザー ID もしくは実効グループ ID
+が親名前空間にマッピングがない (\fBuser_namespaces\fP(7) 参照)。
.TP
\fBEPERM\fP (Linux 3.9 以降)
.\" commit 3151527ee007b73a0ebd296010f1c0454a919c7d
.\" FIXME What is the rationale for this restriction?
-\fBCLONE_NEWUSER was specified in\fP \fIflags\fP and the caller is in a chroot
-environment (i.e., the caller's root directory does not match the root
-directory of the mount namespace in which it resides).
+\fBCLONE_NEWUSER\fP が \fIflags\fP に指定され、 呼び出し元が chroot された環境にいる (すなわち、呼び出し元の root
+ディレクトリが呼び出し元が属するマウント名前空間の root ディレクトリに一致しない)。
.TP
\fBEUSERS\fP (Linux 3.11 以降)
-\fBCLONE_NEWUSER\fP was specified in \fIflags\fP, and the call would cause the
-limit on the number of nested user namespaces to be exceeded. See
-\fBuser_namespaces\fP(7).
+\fBCLONE_NEWUSER\fP が \fIflags\fP に指定されており、 この呼び出しによりネストされたユーザー名前空間数の上限を超えてしまう。
+\fBuser_namespaces\fP(7) を参照。
.SH バージョン
libc5 には \fBclone\fP() はない。glibc2 では \fBclone\fP() が提供されており、このマニュアルページに記載の通りである。
.SH 準拠
\fBcaddr_t create_module(const char *\fP\fIname\fP\fB, size_t \fP\fIsize\fP\fB);\fP
.fi
-\fINote\fP: No declaration of this function is provided in glibc headers; see
-NOTES.
+\fI注意\fP: この関数の宣言は glibc のヘッダーでは提供されていない。「注意」を参照。
.SH 説明
\fI注意\fP: このシステムコールが存在するのは、カーネル 2.6 より前の Linux だけである。
.SH 準拠
\fBcreate_module\fP() は Linux 固有である。
.SH 注意
-The \fBcreate_module\fP() system call is not supported by glibc. No
-declaration is provided in glibc headers, but, through a quirk of history,
-glibc does export an ABI for this system call. Therefore, in order to
-employ this system call, it is sufficient to manually declare the interface
-in your code; alternatively, you can invoke the system call using
-\fBsyscall\fP(2).
+\fBcreate_module\fP() システムコールは glibc ではサポートされていない。 glibc ヘッダーでは宣言は提供されていないが、
+歴史の紆余曲折を経て glibc はこのシステムコールに対する ABI を公開していない。
+したがって、このシステムコールを利用するには、自分のコードの中で手動でインタフェースを宣言すればよい。 \fBsyscall\fP(2)
+を使ってシステムコールを起動できる。
.SH 関連項目
\fBdelete_module\fP(2), \fBinit_module\fP(2), \fBquery_module\fP(2)
.SH この文書について
2つのディスクリプタはファイルディスクリプタフラグ (close\-on\-exec flag) を共有しない。複製されたディスクリプタの
close\-on\-exec flag (\fBfcntl\fP(2) 参照) は off となる。
.SS dup2()
-The \fBdup2\fP() system call performs the same task as \fBdup\fP(), but instead
-of using the lowest\-numbered unused file descriptor, it uses the descriptor
-number specified in \fInewfd\fP. If the descriptor \fInewfd\fP was previously
-open, it is silently closed before being reused.
+\fBdup2\fP() システムコールは \fBdup\fP() と同じ処理を実行するが、
+番号が最も小さい未使用のファイルディスクリプタを使用する代わりに、
+\fInewfd\fP で指定されたディスクリプタ番号を使用する。
+ディスクリプタ \fInewfd\fP が以前にオープンされていた場合には、
+黙ってそのディスクリプタをクローズしてから再利用する。
-The steps of closing and reusing the file descriptor \fInewfd\fP are performed
-\fIatomically\fP. This is important, because trying to implement equivalent
-functionality using \fBclose\fP(2) and \fBdup\fP() would be subject to race
-conditions, whereby \fInewfd\fP might be reused between the two steps. Such
-reuse could happen because the main program is interrupted by a signal
-handler that allocates a file descriptor, or because a parallel thread
-allocates a file descriptor.
+ファイルディスクリプタ \fInewfd\fP をクローズして再利用する処理は
+\fIアトミック(不可分)に\fP実行される。これは重要な点である。 なぜなら、
+等価な機能を \fBclose\fP(2) と \fBdup\fP() を使って実装しようとすると、
+2 つの処理の間に \fInewfd\fP が再利用されてしまうという、
+競合状態にさらされることになるからだ。
+このような再利用が起こるのは、
+メインプログラムがファイルディスクリプタを割り当てる
+シグナルハンドラーにより割り込まれたり、並行動作するスレッドが
+ファイルディスクリプタを割り当てたりすることがあるからだ。
以下の点について注意すること:
.IP * 3
\fInewfd\fP が範囲を超えた時に返されるエラーは、 \fBdup2\fP() と \fBfcntl(\fP..., \fBF_DUPFD\fP, ...\fB)\fP
では異っている。 \fBdup2\fP() が \fBF_DUPFD\fP と同じように \fBEINVAL\fP を返すシステムもある。
-If \fInewfd\fP was open, any errors that would have been reported at
-\fBclose\fP(2) time are lost. If this is of concern, then\(emunless the
-program is single\-threaded and does not allocate file descriptors in signal
-handlers\(emthe correct approach is \fInot\fP to close \fInewfd\fP before calling
-\fBdup2\fP(), because of the race condition described above. Instead, code
-something like the following could be used:
+\fInewfd\fP がオープンされていた場合、
+\fBclose\fP(2) 時に報告されることになるエラーはすべて失われる。
+これが心配で、シングルスレッドかつシグナルハンドラーで
+ファイルディスクリプタを割り当てるようなプログラムでない場合には、
+正しい方法は \fBdup2\fP() を呼び出す前に
+\fInewfd\fP をクローズ「しない」ことである。
+なぜなら、上で説明した競合状況があるからである。
+代わりに、以下のようなコードが使用できることだろう。
.nf
- /* Obtain a duplicate of 'newfd' that can subsequently
- be used to check for close() errors; an EBADF error
- means that 'newfd' was not open. */
+ /* あとで close() エラーをチェックするのに使用できる
+ ように 'newfd' の複製を取得する。 EBADF エラーは
+ 'newfd' がオープンされていないことを意味する。 */
tmpfd = dup(newfd);
if (tmpfd == \-1 && errno != EBADF) {
- /* Handle unexpected dup() error */
+ /* 予期しない dup() のエラーを処理する */
}
- /* Atomically duplicate 'oldfd' on 'newfd' */
+ /* アトミックに 'oldfd' を 'newfd' に複製する */
if (dup2(oldfd, newfd) == \-1) {
- /* Handle dup2() error */
+ /* dup2() のエラーを処理する */
}
- /* Now check for close() errors on the file originally
- referred to by 'newfd' */
+ /* ここでもともと 'newfd' で参照されていたファイルの
+ close() エラーをチェックする */
if (tmpfd != \-1) {
if (close(tmpfd) == \-1) {
- /* Handle errors from close */
+ /* close からのエラーを処理する */
}
}
.fi
.TP
\fBEPOLLWAKEUP\fP (Linux 3.5 以降)
.\" commit 4d7e30d98939a0340022ccd49325a3d70f7e0238
-If \fBEPOLLONESHOT\fP and \fBEPOLLET\fP are clear and the process has the
-\fBCAP_BLOCK_SUSPEND\fP capability, ensure that the system does not enter
-"suspend" or "hibernate" while this event is pending or being processed.
-The event is considered as being "processed" from the time when it is
-returned by a call to \fBepoll_wait\fP(2) until the next call to
-\fBepoll_wait\fP(2) on the same \fBepoll\fP(7) file descriptor, the closure of
-that file descriptor, the removal of the event file descriptor with
-\fBEPOLL_CTL_DEL\fP, or the clearing of \fBEPOLLWAKEUP\fP for the event file
-descriptor with \fBEPOLL_CTL_MOD\fP. See also BUGS.
+\fBEPOLLONESHOT\fP と \fBEPOLLET\fP がクリアされており、 プロセスが \fBCAP_BLOCK_SUSPEND\fP
+ケーパビリティを持っている場合、 イベントが処理待ちか処理中かにかかわらず、必ずシステムが "suspend" や "hibernate"
+に入らないようにすること。 \fBepoll_wait\fP(2) の呼び出しが返った時点から、 同じ \fBepoll\fP(7) ファイルディスクリプタに対して
+\fBepoll_wait\fP(2) が次に呼び出されるか、 そのファイルディスクリプタが閉じられるか、 イベントファイルディスクリプタが
+\fBEPOLL_CTL_DEL\fP で削除されるか、 \fBEPOLL_CTL_MOD\fP でイベントファイルディスクリプタの \fBEPOLLWAKEUP\fP
+がクリアされるか、 のいずれかになるまで、イベントは「処理中」であるとみなされる。 「バグ」の節も参照のこと。
.SH 返り値
成功した場合、 \fBepoll_ctl\fP() は 0 を返す。 エラーが起こった場合、 \fBepoll_ctl\fP() は \-1 を返し、
\fIerrno\fP を適切に設定する。
\fI/proc/sys/fs/epoll/max_user_watches\fP で決まる上限に達した。 詳細は \fBepoll\fP(7) を参照。
.TP
\fBEPERM\fP
-The target file \fIfd\fP does not support \fBepoll\fP. This error can occur if
-\fIfd\fP refers to, for example, a regular file or a directory.
+対象ファイル \fIfd\fP が \fBepoll\fP に対応していない。 このエラーは \fIfd\fP
+が例えば通常ファイルやディレクトリを参照している場合にも起こり得る。
.SH バージョン
.\" To be precise: kernel 2.5.44.
.\" The interface should be finalized by Linux kernel 2.5.66.
.\" commit a8159414d7e3af7233e7a5a82d1c5d85379bd75c (behavior change)
.\" https://lwn.net/Articles/520198/
-If \fBEPOLLWAKEUP\fP is specified in \fIflags\fP, but the caller does not have the
-\fBCAP_BLOCK_SUSPEND\fP capability, then the \fBEPOLLWAKEUP\fP flag is \fIsilently
-ignored\fP. This unfortunate behavior is necessary because no validity checks
-were performed on the \fIflags\fP argument in the original implementation, and
-the addition of the \fBEPOLLWAKEUP\fP with a check that caused the call to fail
-if the caller did not have the \fBCAP_BLOCK_SUSPEND\fP capability caused a
-breakage in at least one existing user\-space application that happened to
-randomly (and uselessly) specify this bit. A robust application should
-therefore double check that it has the \fBCAP_BLOCK_SUSPEND\fP capability if
-attempting to use the \fBEPOLLWAKEUP\fP flag.
+\fIflags\fP に \fBEPOLLWAKEUP\fP が指定されたが、呼び出し元が \fBCAP_BLOCK_SUSPEND\fP
+ケーパビリティを持っていない場合、 \fBEPOLLWAKEUP\fP フラグは \fI黙って無視される\fP。 元の実装では \fIflags\fP
+引き数に対する正当性チェックが実行されていないため、 この残念な動作は必要である。 また、 呼び出し元が \fBCAP_BLOCK_SUSPEND\fP
+ケーパビリティを持っていなかった場合に呼び出しを失敗させるようにチェックを \fBEPOLLWAKEUP\fP に追加すると、
+少なくともひとつは動かなくなる既存のユーザー空間アプリケーションがあった。 そのアプリケーションはたまたま (しかも意味もなく)
+このビットを指定していた。 したがって、信頼性が求められるアプリケーションでは、 \fBEPOLLWAKEUP\fP フラグを使おうする場合には
+\fBCAP_BLOCK_SUSPEND\fP ケーパビリティを持っているかも確認するようにすべきである。
.SH 関連項目
\fBepoll_create\fP(2), \fBepoll_wait\fP(2), \fBpoll\fP(2), \fBepoll\fP(7)
.SH この文書について
.TP
\fBEAGAIN\fP (Linux 3.1 以降)
.\" commit 72fa59970f8698023045ab0713d66f3f4f96945c
-Having changed its real UID using one of the \fBset*uid\fP() calls, the caller
-was\(emand is now still\(emabove its \fBRLIMIT_NPROC\fP resource limit (see
-\fBsetrlimit\fP(2)). For a more detailed explanation of this error, see NOTES.
+\fBset*uid\fP() のいずれかの呼び出しでプロセスの実 UID が変更されたとすると、呼び出し元の \fBRLIMIT_NPROC\fP リソース上限
+(\fBsetrlimit\fP(2) 参照) を超えてしまう、 現在もまだ超えている。 このエラーの詳細な説明については「注意」の節を参照。
.TP
\fBEFAULT\fP
\fIfilename\fP または配列 \fIargv\fP か \fIenvp\fP のポインタの一つがアクセス可能なアドレス空間の外を指している。
.\" that could be exploited for denial of service by a suitably crafted
.\" ELF binary. There are no known problems with 2.0.34 or 2.2.15.
Linux はスクリプトの set\-user\-ID と set\-group\-ID ビットを無視する。
-.SS "execve() and EAGAIN"
-A more detailed explanation of the \fBEAGAIN\fP error that can occur (since
-Linux 3.1) when calling \fBexecve\fP() is as follows.
+.SS "execve() と EAGAIN"
+\fBexecve\fP() を呼び出した際に (Linux 3.1 以降で) 起こり得る \fBEAGAIN\fP エラーの詳細な説明を以下で行う。
.\" commit 909cc4ae86f3380152a18e2a3c44523893ee11c4
-The \fBEAGAIN\fP error can occur when a \fIpreceding\fP call to \fBsetuid\fP(2),
-\fBsetreuid\fP(2), or \fBsetresuid\fP(2) caused the real user ID of the process
-to change, and that change caused the process to exceed its \fBRLIMIT_NPROC\fP
-resource limit (i.e., the number of processes belonging to the new real UID
-exceeds the resource limit). From Linux 2.6.0 to 3.0, this caused the
-\fBset*uid\fP() call to fail. (Prior to 2.6, the resource limit was not
-imposed on processes that changed their user IDs.)
-
-Since Linux 3.1, the scenario just described no longer causes the
-\fBset*uid\fP() call to fail, because it too often led to security holes where
-buggy applications didn't check the return status and assumed that\(emif the
-caller had root privileges\(emthe call would always succeed. Instead, the
-\fBset*uid\fP() calls now successfully change the real UID, but the kernel
-sets an internal flag, named \fBPF_NPROC_EXCEEDED\fP, to note that the
-\fBRLIMIT_NPROC\fP resource limit has been exceeded. If the
-\fBPF_NPROC_EXCEEDED\fP flag is set and the resource limit is still exceeded at
-the time of a subsequent \fBexecve\fP() call, that call fails with the error
-\fBEAGAIN\fP. This kernel logic ensures that the \fBRLIMIT_NPROC\fP resource
-limit is still enforced for the common privileged daemon workflow\(emnamely,
-\fBfork\fP(2) + \fBset*uid\fP() + \fBexecve\fP().
-
-If the resource limit was not still exceeded at the time of the \fBexecve\fP()
-call (because other processes belonging to this real UID terminated between
-the \fBset*uid()\fP call and the \fBexecve\fP() call), then the \fBexecve\fP() call
-succeeds and the kernel clears the \fBPF_NPROC_EXCEEDED\fP process flag. The
-flag is also cleared if a subsequent call to \fBfork\fP(2) by this process
-succeeds.
+\fI直前の\fP \fBsetuid\fP(2), \fBsetreuid\fP(2), \fBsetresuid\fP(2) の呼び出しで、 そのプロセスの実ユーザー ID
+が変更され、 その変更によりそのプロセスが \fBRLIMIT_NPROC\fP リソース上限を超過してしまった場合 (すなわち、新しい実ユーザー ID
+に属するプロセス数が \fBRLIMIT_NPROC\fP リソース上限を超過した場合) に、 \fBEAGAIN\fP エラーが発生する。 Linux 2.6.0
+以上 3.0 以下では、これにより \fBset*uid\fP() の呼び出しが失敗していた。 (Linux 2.6 より前では、このリソース上限はユーザー
+ID を変更したプロセスには適用されていなかった。)
+
+Linux 3.1 以降では、上で説明したシナリオでは \fBset*uid\fP() の呼び出しは失敗しない。 なぜなら、
+返されたステータスの確認を行わず「呼び出し元が特権を持っている場合には」呼び出しは必ず成功するとみなしているバグがあるアプリケーションでは、セキュリティホールにつながることが非常によくあるからだ。
+その代わり、 \fBset*uid\fP() の呼び出しによる実 UID の変更は成功するが、 カーネルは \fBPF_NPROC_EXCEEDED\fP
+という名前の内部フラグをセットする。 このフラグは \fBRLIMIT_NPROC\fP リソース上限が超過したことを示す。
+\fBPF_NPROC_EXCEEDED\fP フラグがセットされていて、その後で \fBexecve\fP() が呼ばれた際にリソース上限がまだ超過していれば、
+その \fBexecve\fP() の呼び出しは \fBEAGAIN\fP エラーで失敗する。 このカーネルのロジックにより、
+特権デーモンでよく行われる処理フロー、 すなわち \fBfork\fP(2) + \fBset*uid\fP() + \fBexecve\fP()
+に対して、前と変わらず \fBRLIMIT_NPROC\fP リソース上限を適用できることが保証される。
+
+(\fBset*uid\fP() と \fBexecve\fP() の呼び出しの間に、この実 UID に属する他のプロセスが終了して) 次に \fBexecve\fP()
+が呼び出された際にこのリソース上限が超過してなければ、 \fBexecve\fP() の呼び出しは成功し、カーネルは \fBPF_NPROC_EXCEEDED\fP
+プロセスフラグをクリアする。 同じプロセスによって \fBfork\fP(2) の呼び出しが後で行われた場合にも、このフラグはクリアされる。
.SS 歴史
.\"
.\" .SH BUGS
.SS ファイル空間の一部削除
.\" commit 00f5e61998dd17f5375d9dfc01331f104b83f841
\fBFALLOC_FL_COLLAPSE_RANGE\fP フラグ (Linux 3.15 以降で利用可能) を \fImode\fP に指定すると、
-æ\8c\87å®\9aã\81\97ã\81\9fã\83\90ã\82¤ã\83\88ç¯\84å\9b²ã\82\92ã\83\95ã\82¡ã\82¤ã\83«ã\81\8bã\82\89å\89\8aé\99¤ã\81\99ã\82\8bã\80\82 ã\81\9dã\81®é\9a\9bã\80\81ã\83\9bã\83¼ã\83«ã\82\92æ®\8bã\82\89ない。 削除されるバイト範囲は \fIoffset\fP から始まる \fIlen\fP
+æ\8c\87å®\9aã\81\97ã\81\9fã\83\90ã\82¤ã\83\88ç¯\84å\9b²ã\82\92ã\83\95ã\82¡ã\82¤ã\83«ã\81\8bã\82\89å\89\8aé\99¤ã\81\99ã\82\8bã\80\82 ã\81\9dã\81®é\9a\9bã\80\81ã\83\9bã\83¼ã\83«ã\82\92æ®\8bã\81\95ない。 削除されるバイト範囲は \fIoffset\fP から始まる \fIlen\fP
バイトの範囲である。 操作が完了すると、 ファイルの \fIoffset+len\fP の位置から始まる内容が \fIoffset\fP の位置に見えるようになり、
ファイルのサイズは \fIlen\fP バイトだけ小さくなる。
でサポートされている。
.SS ファイル空間のゼロ埋め
.\" commit 409332b65d3ed8cfa7a8030f1e9d52f372219642
-Specifying the \fBFALLOC_FL_ZERO_RANGE\fP flag (available since Linux 3.14) in
-\fImode\fP zeroes space in the byte range starting at \fIoffset\fP and continuing
-for \fIlen\fP bytes. Within the specified range, blocks are preallocated for
-the regions that span the holes in the file. After a successful call,
-subsequent reads from this range will return zeroes.
+\fBFALLOC_FL_ZERO_RANGE\fP フラグ (Linux 3.14 以降で利用可能) を \fImode\fP に指定すると、 \fIoffset\fP
+で始まる \fIlen\fP バイト範囲の空間をゼロ埋めする。
+指定された範囲の中では、ブロックは、そのファイル内のホールが広がる領域にあらかじめ割り当てられたものである。 呼び出しが成功すると、
+これ以降のこの範囲からの読み出しでは 0 を返す。
-Zeroing is done within the filesystem preferably by converting the range
-into unwritten extents. This approach means that the specified range will
-not be physically zeroed out on the device (except for partial blocks at the
-either end of the range), and I/O is (otherwise) required only to update
-metadata.
+ゼロ埋めは、ファイルシステム内部では、指定された範囲を書き込みを伴わないエクステントに変換する方法をできるだけ使って行われる。
+この方法は、指定された範囲について物理的にゼロ埋めしたデータがデバイスに書き込まれるのではないことを意味する
+(例外は指定された範囲の端の部分的に使用しているブロックである)。 (これ以外で) I/O が必要なのはメタデータの更新だけである。
-If the \fBFALLOC_FL_KEEP_SIZE\fP flag is additionally specified in \fImode\fP, the
-behavior of the call is similar, but the file size will not be changed even
-if \fIoffset\fP+\fIlen\fP is greater than the file size. This behavior is the
-same as when preallocating space with \fBFALLOC_FL_KEEP_SIZE\fP specified.
+\fBFALLOC_FL_KEEP_SIZE\fP フラグが \fImode\fP に追加で指定された場合、 このシステムコールの動作は似ているが、
+\fIoffset\fP+\fIlen\fP がファイルサイズよりも大きい場合であってもファイルサイズは変更されない点が異なる。 この動作は
+\fBFALLOC_FL_KEEP_SIZE\fP を指定してスペースを前もって割り当てた場合と同じである。
すべてのファイルシステムで \fBFALLOC_FL_ZERO_RANGE\fP がサポートされているわけではない。
ファイルシステムがこの操作をサポートしていない場合は、 エラーが返る。 この操作は少なくとも以下のファイルシステムでサポートされている。
XFS (Linux 3.14 以降)
.IP *
.\" commit b8a8684502a0fc852afa0056c6bb2a9273f6fcc0
-ext4, for extent\-based files (since Linux 3.14)
+ext4 のエクステントベースのファイル (Linux 3.14 以降)
.SH 返り値
成功の場合、 \fBfallocate\fP() は 0 を返す。 エラーの場合、\-1 を返し、 \fIerrno\fP にエラーを示す値を設定する。
.SH エラー
\fB struct itimerval *\fP\fIold_value\fP\fB);\fP
.fi
.SH 説明
-The system provides each process with three interval timers, each
-decrementing in a distinct time domain. When a timer expires, a signal is
-sent to the process, and the timer is reset to the specified interval (if
-nonzero).
+システムは 1 個のプロセスにつき 3 個のインターバル・タイマーを提供する。 それぞれのタイマーは別々の時間領域で減少する。
+あるタイマーが満了すると、 プロセスにシグナルが送られ、 タイマーは (0 でなければ) 指定されたインターバルに再設定される。
.TP 1.5i
\fBITIMER_REAL\fP
実時間 (real time) で減少し、満了すると \fBSIGALRM\fP が送られる。
.in
.PD
.LP
-The function \fBgetitimer\fP() fills the structure pointed to by \fIcurr_value\fP
-with the current value (i.e., the amount of time remaining until the next
-expiration) of the timer specified by \fIwhich\fP (one of \fBITIMER_REAL\fP,
-\fBITIMER_VIRTUAL\fP, or \fBITIMER_PROF\fP). The subfields of the field
-\fIit_value\fP are set to the amount of time remaining on the timer, or zero if
-the timer is disabled. The \fIit_interval\fP field is set to the timer
-interval (period); a value of zero returned in (both subfields of) this
-field indicates that this is a single\-shot timer.
+\fBgetitimer\fP() 関数は、 \fIwhich\fP で指定されたタイマー (\fBITIMER_REAL\fP, \fBITIMER_VIRTUAL\fP,
+\fBITIMER_PROF\fP のどれか) の現在の値 (すなわち、次のタイマー満了までの残り時間) を、 \fIcurr_value\fP
+で指定された構造体に格納する。 \fIit_value\fP フィールドのサブフィールドにはタイマーの残り時間が設定される。 タイマーが無効になっている場合は
+ゼロが設定される。 \fIit_interval\fP フィールドにはタイマーのインターバル (期間) が設定される。 \fIit_interval\fP
+(の両方のサブフィールド) で値 0 が返された場合は、 このタイマーが 1 回限りのタイマーであることを示している。
-The function \fBsetitimer\fP() sets the specified timer to the value in
-\fInew_value\fP. If \fIold_value\fP is non\-NULL, the old value of the timer
-(i.e., the same information as returned by \fBgetitimer\fP()) is stored there.
+\fBsetitimer\fP() 関数は指定されたタイマーに \fInew_value\fP の値を設定する。 \fIold_value\fP が NULL
+以外の場合、タイマーの古い値 (すなわち \fBgetitimer\fP() で返されるのと同じ情報) が \fIold_value\fP に格納される。
.LP
タイマーは \fIit_value\fP からゼロへ向けて減っていき、シグナルを生成し、 \fIit_interval\fP に初期化される。
タイマーがゼロに設定された場合 (\fIit_value\fP がゼロか、タイマーが満了した時に \fIit_interval\fP がゼロの場合) は停止する。
がプロセス \fIwho\fP の実 UID か実効 UID のいずれかと一致する必要がある。 全ての BSD 風システム (SunOS 4.1.3,
Ultrix 4.2, 4.3BSD, FreeBSD 4.3, OpenBSD\-2.5等) は、 Linux 2.6.12 以降と同じ動作をする。
.LP
-The actual priority range varies between kernel versions. Linux before
-1.3.36 had \-infinity..15. Since kernel 1.3.43, Linux has the range
-\-20..19. On some other systems, the range of nice values is \-20..20.
+実際の優先度の範囲はカーネルのバージョンにより異なる。 バージョン 1.3.36 より前の Linux では
+\-infinity(マイナス無限大)..15 である。 カーネル 1.3.43 以降の Linux では、 \-20..19 である。
+他のいくつかのシステムでは、この範囲が \-20..20 である。
.\"
現在では \fI<sys/time.h>\fP をインクルードする必要はないが、インクルードすれば移植性を高めることができる (実際には
\fI<sys/resource.h>\fP で \fIrusage\fP 構造体が定義されているが、そのフィールドで使用されている
\fIstruct timeval\fP 型は \fI<sys/time.h>\fP で定義されている)。
-.SS "C library/kernel ABI differences"
-Within the kernel, nice values are actually represented using the range
-40..1 (since negative numbers are error codes) and these are the values
-employed by the \fBsetpriority\fP() and \fBgetpriority\fP() system calls. The
-glibc wrapper functions for these system calls handle the translations
-between the user\-land and kernel representations of the nice value according
-to the formula \fIunice\ =\ 20\ \-\ knice\fP. (Thus, the kernels 40..1 range
-corresponds to the range \-20..19 as seen by user space.)
+.SS "C ライブラリとカーネル ABI の違い"
+カーネル内部では、nice 値は実際には 40 〜 1 の範囲を使って 表現されており (負の値はエラーコードとなるため)、こちらの値が システムコール
+\fBsetpriority\fP() と \fBgetpriority\fP() で使用されている。 glibc
+のこれらのシステムコールのラッパー関数において、nice 値の ユーザ領域 (user\-land) とカーネル表現の間の変換が行われる。 変換式は
+\fIunice\ =\ 20\ \-\ knice\fP となる。 (したがって、カーネルの 40..1 の範囲はユーザー空間で見える \-20..19
+の範囲に対応する。)
.SH バグ
POSIX では nice 値はプロセス単位の設定となっている。 一方、 現在の POSIX スレッドの Linux/NPTL 実装では、 nice
値はスレッド単位の属性である。 同じプロセスの別々のスレッドが異なる nice 値を持つ場合がある。 移植性が必要なアプリケーションではこの Linux
以下の式により計算され、(そのキューが削除されるまでの間) この制限の計算対象に含められる。
.nf
- Since Linux 3.5:
+ Linux 3.5 以降:
bytes = attr.mq_maxmsg * sizeof(struct msg_msg) +
min(attr.mq_maxmsg, MQ_PRIO_MAX) *
sizeof(struct posix_msg_tree_node)+
- /* For overhead */
+ /* オーバーヘッド分 */
attr.mq_maxmsg * attr.mq_msgsize;
- /* For message data */
+ /* メッセージデータ分 */
- Linux 3.4 and earlier:
+ Linux 3.4 以前:
bytes = attr.mq_maxmsg * sizeof(struct msg_msg *) +
- /* For overhead */
+ /* オーバーヘッド分 */
attr.mq_maxmsg * attr.mq_msgsize;
- /* For message data */
+ /* メッセージデータ分 */
.fi
-where \fIattr\fP is the \fImq_attr\fP structure specified as the fourth argument
-to \fBmq_open\fP(3), and the \fImsg_msg\fP and \fIposix_msg_tree_node\fP structures
-are kernel\-internal structures.
-
-The "overhead" addend in the formula accounts for overhead bytes required by
-the implementation and ensures that the user cannot create an unlimited
-number of zero\-length messages (such messages nevertheless each consume some
-system memory for bookkeeping overhead).
+ここで \fIattr\fP は \fImq_attr\fP 構造体であり、 \fBmq_open\fP(3) の第 4 引き数として指定される。 また、構造体
+\fImsg_msg\fP と \fIposix_msg_tree_node\fP はカーネル内部の構造体である。
+
+上記の式での「オーバーヘッド」加算分は、実装において必要となるオーバーヘッドを考慮したものである。 また、これにより、ユーザーが長さ 0
+のメッセージを無制限に作れないことが保証される (このようなメッセージであっても、 記録のためのオーバーヘッドでシステムメモリを消費する)。
.TP
\fBRLIMIT_NICE\fP (Linux 2.6.12 以降, 下記の「バグ」の節も参照)
\fBsetpriority\fP(2) や \fBnice\fP(2) を使って引き上げられるプロセスの nice 値の上限を指定する。 nice
\fIpathname\fP のどのイベントを監視するかは、引き数のビットマスク \fImask\fP で指定する。 \fImask\fP
に設定できるビットの説明については \fBinotify\fP(7) を参照のこと。
-A successful call to \fBinotify_add_watch\fP() returns a unique watch
-descriptor for this inotify instance, for the filesystem object that
-corresponds to \fIpathname\fP. If the filesystem object was not previously
-being watched by this inotify instance, then the watch descriptor is newly
-allocated. If the filesystem object was already being watched (perhaps via
-a different link to the same object), then the descriptor for the existing
-watch is returned.
+\fBinotify_add_watch\fP() の呼び出しが成功すると、 \fIpathname\fP に対応するファイルシステムオブジェクトに対する、
+一意な監視対象ディスクリプタ (watch descriptor) を、 対象の inotify インスタンスに対して返す。
+そのファイルシステムオブジェクトが対象の inotify インスタンスによって以前に監視されていない場合には、
+監視対象ディスクリプタは新規に割り当てられる。 ファイルシステムオブジェクトが (おそらく同じオブジェクトに対する異なるリンク経由で)
+すでに監視されている場合には、 既存の監視に対するディスクリプタが返される。
これ以降に inotify ファイルディスクリプタから \fBread\fP(2) を行うと、監視対象ディスクリプタが返される。 これらの
\fBread\fP() を行うと、ファイルシステムイベントを示す \fIinotify_event\fP 構造体が読み出される (\fBinotify\fP(7)
いずれか一つを (OR で) 指定する。指定するアーキテクチャは、
システムの CPU で実行可能なものでなければならない。
-The \fIentry\fP argument is the physical entry address in the kernel image.
-The \fInr_segments\fP argument is the number of segments pointed to by the
-\fIsegments\fP pointer; the kernel imposes an (arbitrary) limit of 16 on the
-number of segments. The \fIsegments\fP argument is an array of
-\fIkexec_segment\fP structures which define the kernel layout:
+\fIentry\fP 引き数は、カーネルイメージの物理エントリーアドレスである。 \fInr_segments\fP 引き数は、 \fIsegments\fP
+ポインタが指すセグメントの数である。 なお、セグメント数には、カーネルにより 16 という (強制的な) 上限が課される。 \fIsegments\fP
+引き数は \fIkexec_segment\fP 構造体の配列で、 この構造体によりカーネルの配置が定義される。
.in +4n
.nf
\fBAT_EMPTY_PATH\fP (Linux 2.6.39 以降)
.\" commit 11a7b371b64ef39fc5fb1b6f2218eef7c4d035e3
.\" Before glibc 2.16, defining _ATFILE_SOURCE sufficed
-If \fIoldpath\fP is an empty string, create a link to the file referenced by
-\fIolddirfd\fP (which may have been obtained using the \fBopen\fP(2) \fBO_PATH\fP
-flag). In this case, \fIolddirfd\fP can refer to any type of file, not just a
-directory. This will generally not work if the file has a link count of
-zero (files created with \fBO_TMPFILE\fP and without \fBO_EXCL\fP are an
-exception). The caller must have the \fBCAP_DAC_READ_SEARCH\fP capability in
-order to use this flag. This flag is Linux\-specific; define \fB_GNU_SOURCE\fP
-to obtain its definition.
+\fIoldpath\fP が空文字列の場合、 \fIolddirfd\fP が参照するファイルへのリンクを作成する (\fIolddirfd\fP は
+\fBopen\fP(2) の \fBO_PATH\fP フラグを使って取得する)。 この場合、 \fIolddirfd\fP
+はディレクトリ以外の任意の型のファイルを参照することができる。 一般的には、 ファイルのリンクカウントが 0 の場合は、この操作は成功しない (ただし、
+\fBO_TMPFILE\fP が指定され \fBO_EXCL\fP を指定せずに作成されたファイルは例外である)。 このフラグを使用するためには、 呼び出し元は
+\fBCAP_DAC_READ_SEARCH\fP ケーパビリティを持っていなければならない。 このフラグは Linux 固有で、 この定義を得るには
+\fB_GNU_SOURCE\fP を定義すること。
.TP
\fBAT_SYMLINK_FOLLOW\fP (Linux 2.6.18 以降)
-By default, \fBlinkat\fP(), does not dereference \fIoldpath\fP if it is a symbolic
-link (like \fBlink\fP()). The flag \fBAT_SYMLINK_FOLLOW\fP can be specified in
-\fIflags\fP to cause \fIoldpath\fP to be dereferenced if it is a symbolic link.
-If procfs is mounted, this can be used as an alternative to
-\fBAT_EMPTY_PATH\fP, like this:
+\fBlinkat\fP() は (\fBlink\fP() 同様) デフォルトでは \fIoldpath\fP がシンボリックリンクの場合リンクの展開を行わない。
+フラグ \fBAT_SYMLINK_FOLLOW\fP を \fIflags\fP に指定することができ、指定した場合 \fIoldpath\fP
+がシンボリックリンクの場合リンクの展開が行われる。 procfs がマウントされている場合、これは \fBAT_EMPTY_PATH\fP
+の代替として以下のように使うことができる。
.nf
.in +4n
\fBopen\fP(2) 参照。
.TP
\fBENOENT\fP
-\fIoldpath\fP is a relative pathname and \fIolddirfd\fP refers to a directory that
-has been deleted, or \fInewpath\fP is a relative pathname and \fInewdirfd\fP
-refers to a directory that has been deleted.
+\fIoldpath\fP が相対パス名で、 \fIolddirfd\fP が削除されたディレクトリを参照している。 または、 \fInewpath\fP
+が相対パス名で、 \fInewdirfd\fP が削除されたディレクトリを参照している。
.TP
\fBENOTDIR\fP
\fIoldpath\fP が相対パスで、 \fIolddirfd\fP がディレクトリ以外のファイルを参照している。または \fInewpath\fP と
がシンボリックリンクの場合にシンボリックリンクの参照を 解決するかどうかは実装依存となった。
リンク作成時のシンボリックリンクの扱いについての詳細な制御を行う場合には \fBlinkat\fP(2) を使用すること。
.SS "glibc での注意"
-On older kernels where \fBlinkat\fP() is unavailable, the glibc wrapper
-function falls back to the use of \fBlink\fP(), unless the \fBAT_SYMLINK_FOLLOW\fP
-is specified. When \fIoldpath\fP and \fInewpath\fP are relative pathnames, glibc
-constructs pathnames based on the symbolic links in \fI/proc/self/fd\fP that
-correspond to the \fIolddirfd\fP and \fInewdirfd\fP arguments.
+\fBlinkat\fP() が利用できない古いカーネルでは、 \fBAT_SYMLINK_FOLLOW\fP が指定されていない場合、 glibc ラッパー関数は
+\fBlink\fP() を使用するモードにフォールバックする。 \fIoldpath\fP と \fInewpath\fP が相対パスの場合、 glibc は
+\fIolddirfd\fP と \fInewdirfd\fP 引き数に対応する \fI/proc/self/fd\fP
+のシンボリックリンクに基づいてそれぞれパス名を構成する。
.SH バグ
NFS ファイルシステムでは、NFS サーバーがリンクを作成した後に、 それを伝える前に死んだ場合には返り値が不正な場合がある。
リンクが作成できたかどうか見つけるためには \fBstat\fP(2) を使用すること。
\fBSEEK_DATA\fP と \fBSEEK_HOLE\fP は非標準の拡張で、 Solaris, FreeBSD, DragonFly BSD
にも存在する。 これらは POSIX の次の版 (Issue 8) に入れるよう提案されている。
.SH 注意
-See \fBopen\fP(2) for a discussion of the relationship between file
-descriptors, open file descriptions, and files.
+ファイルディスクリプタ、オープンファイル記述、ファイルの関係の説明については \fBopen\fP(2) を参照。
いくつかのデバイスでは seek ができない。 POSIX はどのデバイスが \fBlseek\fP() に対応すべきかは規定していない。
指定した範囲のアドレスが、現在マップされていない。 あるいはプロセスのアドレス空間の内部にない。
.SH バージョン
.\" commit d3ac21cacc24790eb45d735769f35753f5b56ceb
-Since Linux 3.18, support for this system call is optional, depending on the
-setting of the \fBCONFIG_ADVISE_SYSCALLS\fP configuration option.
+Linux 3.18 以降では、このシステムコールのサポートは任意となり、利用できるかはカーネルが \fBCONFIG_ADVISE_SYSCALLS\fP
+オプションを有効にしてコンパイルされているかに依存する。
.SH 準拠
.\" FIXME . Write a posix_madvise(3) page.
POSIX.1b. POSIX.1\-2001 では、 \fBposix_madvise\fP(3) を \fBPOSIX_MADV_NORMAL\fP,
\fBread\fP(2) では一度に一つパケットが読み出される。 以下の点に注意すること。
.RS
.IP * 3
-Writes of greater than \fBPIPE_BUF\fP bytes (see \fBpipe\fP(7)) will be split
-into multiple packets. The constant \fBPIPE_BUF\fP is defined in
-\fI<limits.h>\fP.
+\fBPIPE_BUF\fP バイト (\fBpipe\fP(7) 参照) より大きいデータを書き込んだ場合、複数のパケットに分割される。
+定数 \fBPIPE_BUF\fP は \fI<limits.h>\fP で定義されている。
.IP *
\fBread\fP(2)
で次のパケットよりも小さなバッファサイズを指定した場合、要求されたバイト数のデータが読み出され、そのパケットの超過分のバイトは破棄される。
データを受信した場合や、 パケットモードの擬似端末のマスタがスレーブ側の変化を見つけたとき)。
.TP
\fBPOLLOUT\fP
-Writing is now possible, though a write larger that the available space in a
-socket or pipe will still block (unless \fBO_NONBLOCK\fP is set).
+書き込みが可能になった。ただし、ソケットやパイプで利用可能な空間よりも大きなデータを書き込んだ場合には (\fBO_NONBLOCK\fP
+がセットされている場合以外は) やはり停止することになる。
.TP
\fBPOLLRDHUP\fP (Linux 2.6.17 以降)
ストリームソケットの他端が、コネクションを close したか、 コネクションの書き込み側を shutdown した。 この定義を有効にするには、
のラッパー関数は、システムコールに渡す timeout 引き数 としてローカル変数を使うことでこの動作を隠蔽している。 このため、glibc の
\fBppoll\fP() 関数では \fItimeout_ts\fP 引き数は変更されない。
-The raw \fBppoll\fP() system call has a fifth argument, \fIsize_t sigsetsize\fP,
-which specifies the size in bytes of the \fIsigmask\fP argument. The glibc
-\fBppoll\fP() wrapper function specifies this argument as a fixed value (equal
-to \fIsizeof(sigset_t)\fP).
+素の \fBppoll\fP() システムコールは 5 番目の引き数 \fIsize_t sigsetsize\fP をとる。 この引き数は \fIsigmask\fP
+引き数のバイト単位のサイズを指定する。 glibc の \fBppoll\fP() ラッパー関数は、この引き数に固定値
+(\fIsizeof(sigset_t)\fP と同じ) を指定する。
.SH バグ
\fBselect\fP(2) の「バグ」の節に書かれている、誤った準備完了通知 (spurious readiness notifications)
についての議論を参照のこと。
\fB size_t \fP\fIbufsize\fP\fB, size_t *\fP\fIret\fP\fB);\fP
.fi
-\fINote\fP: No declaration of this function is provided in glibc headers; see
-NOTES.
+\fI注意\fP: この関数の宣言は glibc のヘッダーでは提供されていない。「注意」を参照。
.SH 説明
\fI注意\fP: このシステムコールが存在するのは、カーネル 2.6 より前の Linux だけである。
以前 \fBquery_module\fP() で得られた情報のいくつかは、 \fI/proc/modules\fP, \fI/proc/kallsyms\fP および
\fI/sys/module\fP ディレクトリ内のファイルから取得できる。
-The \fBquery_module\fP() system call is not supported by glibc. No
-declaration is provided in glibc headers, but, through a quirk of history,
-glibc does export an ABI for this system call. Therefore, in order to
-employ this system call, it is sufficient to manually declare the interface
-in your code; alternatively, you can invoke the system call using
-\fBsyscall\fP(2).
+\fBquery_module\fP() システムコールは glibc ではサポートされていない。 glibc ヘッダーでは宣言は提供されていないが、
+歴史の紆余曲折を経て glibc はこのシステムコールに対する ABI を公開していない。
+したがって、このシステムコールを利用するには、自分のコードの中で手動でインタフェースを宣言すればよい。 \fBsyscall\fP(2)
+を使ってシステムコールを起動できる。
.SH 関連項目
\fBcreate_module\fP(2), \fBdelete_module\fP(2), \fBget_kernel_syms\fP(2),
\fBinit_module\fP(2), \fBlsmod\fP(8), \fBmodinfo\fP(8)
\fIpathname\fP で指定されたパス名が絶対パスの場合、 \fIdirfd\fP は無視される。
.\" commit 65cfc6722361570bfe255698d9cd4dccaf47570d
-Since Linux 2.6.39, \fIpathname\fP can be an empty string, in which case the
-call operates on the symbolic link referred to by \fIdirfd\fP (which should
-have have been obtained using \fBopen\fP(2) with the \fBO_PATH\fP and
-\fBO_NOFOLLOW\fP flags).
+Linux 2.6.39 以降では、 \fIpathname\fP に空文字列を指定できる。 その場合、呼び出しは \fIdirfd\fP
+が参照するシンボリックリンクに対して行われる (\fIdirfd\fP はフラグ \fBO_PATH\fP と \fBO_NOFOLLOW\fP を指定した
+\fBopen\fP(2) を使って取得すべきである)。
.PP
\fBreadlinkat\fP() の必要性についての説明については \fBopenat\fP(2) を参照。
.SH 返り値
なぜなら、POSIX では、 システムがそのような上限値を定義していない場合には、 \fIPATH_MAX\fP
が定義されることが保証されていないからである。
.SS "glibc での注意"
-On older kernels where \fBreadlinkat\fP() is unavailable, the glibc wrapper
-function falls back to the use of \fBreadlink\fP(). When \fIpathname\fP is a
-relative pathname, glibc constructs a pathname based on the symbolic link in
-\fI/proc/self/fd\fP that corresponds to the \fIdirfd\fP argument.
+\fBreadlinkat\fP() が利用できない古いカーネルでは、 glibc ラッパー関数は \fBreadlink\fP()
+を使用するモードにフォールバックする。 \fIpathname\fP が相対パスの場合、 glibc は \fIdirfd\fP 引き数に対応する
+\fI/proc/self/fd\fP のシンボリックリンクに基づいてパス名を構成する。
.SH 例
以下のプログラムは、 \fBreadlink\fP() が必要とするバッファを、
\fBlstat\fP() が提供する情報に基づいて動的に割り当てる。
\fIiov\fP の各要素の \fIiov_base\fP フィールドが指定する場所にコピーしてから、 そのバッファを解放する。 \fBwritev\fP()
のラッパー関数も、同じように一時バッファを使って \fBwrite\fP(2) を呼び出す。
-The raw \fBpreadv\fP() and \fBpwritev\fP() system calls have call signatures
-that differ slightly from that of the corresponding GNU C library wrapper
-functions shown in the SYNOPSIS. The final argument, \fIoffset\fP, is unpacked
-by the wrapper functions into two arguments in the system calls:
+素のシステムコール \fBpreadv\fP() と \fBpwritev\fP() のシグネチャーは、 「書式」に書かれている対応する GNU C
+ライブラリのラッパー関数のものとは少し異なる。 最後の引き数 \fIoffset\fP はラッパー関数によりシステムコールの 2 つの引き数に展開される。
\fB unsigned long \fP\fIpos_l\fP\fB, unsigned long \fP\fIpos\fP
-These arguments contain, respectively, the low order and high order 32 bits
-of \fIoffset\fP.
+これらの引き数は、それぞれ、 \fIoffset\fP の下位 32 ビットと上位 32 ビットである。
.SH バグ
ファイルディスクリプタに対する操作を行う \fBreadv\fP() や \fBwritev\fP() と、
標準入出力ライブラリの関数をごちゃまぜにして呼ぶのはお薦めしない。
\fBrenameat2\fP() は Linux 固有である。
.SH 注意
.SS "glibc での注意"
-On older kernels where \fBrenameat\fP() is unavailable, the glibc wrapper
-function falls back to the use of \fBrename\fP(). When \fIoldpath\fP and
-\fInewpath\fP are relative pathnames, glibc constructs pathnames based on the
-symbolic links in \fI/proc/self/fd\fP that correspond to the \fIolddirfd\fP and
-\fInewdirfd\fP arguments.
+\fBrenameat\fP() が利用できない古いカーネルでは、 glibc ラッパー関数は \fBrename\fP() を使用するモードにフォールバックする。
+\fIoldpath\fP と \fInewpath\fP が相対パスの場合、 glibc は \fIolddirfd\fP と \fInewdirfd\fP 引き数に対応する
+\fI/proc/self/fd\fP のシンボリックリンクに基づいてそれぞれパス名を構成する。
.SH バグ
NFS ファイルシステムでは、操作が失敗したからといって、 ファイルの名前が変更できなかったと決めてかかることはできない。 サーバが rename
操作を終えてからクラッシュした場合、 サーバが再び立ち上がったときに、 再送信された RPC が処理されるが、これは失敗となる。
機構が使用されている場合には、スレッドが動作する CPU 集合 に対してシステムはさらに制限を加えるかもしれない ("cpuset" 機構については
\fBcpuset\fP(7) を参照)。 スレッドが動作する実際の CPU 集合に対する制限はカーネルにより 暗黙のうちに適用される。
-There are various ways of determining the number of CPUs available on the
-system, including: inspecting the contents of \fI/proc/cpuinfo\fP; using
-\fBsyconf\fP(3) to obtain the values of the \fB_SC_NPROCESSORS_CONF\fP and
-\fB_SC_NPROCESSORS_ONLN\fP parameters; and inspecting the list CPU directories
-under \fI/sys/devices/system/cpu/\fP.
+システムで利用可能な CPU 数を判定する方法はいくつかある。 \fI/proc/cpuinfo\fP の内容を調べる、 \fBsysconf\fP(3) を使って
+\fB_SC_NPROCESSORS_CONF\fP と \fB_SC_NPROCESSORS_ONLN\fP の値を取得する、
+\fI/sys/devices/system/cpu/\fP の CPU ディレクトリの一覧を調べる、などがある。
\fBsched\fP(7) に Linux のスケジューリング方式についての説明がある。
.PP
.SH 返り値
成功した場合は 0 が返される。エラーの場合は \-1 が返され、 \fIerrno\fP が適切に設定される。
-\fINote\fP: there are cases where \fBseteuid\fP() can fail even when the caller
-is UID 0; it is a grave security error to omit checking for a failure return
-from \fBseteuid\fP().
+\fI注意\fP: 呼び出し元が UID 0 であっても \fBseteuid\fP() が失敗する場合がある。 \fBseteuid\fP()
+からのリターンが失敗かどうかの確認を省略することは重大なセキュリティ上のエラーとなる。
.SH エラー
.TP
\fBEINVAL\fP
-The target user or group ID is not valid in this user namespace.
+対象のユーザー ID かグループ ID がこのユーザー名前空間では有効ではない。
.TP
\fBEPERM\fP
呼び出し元のプロセスに特権がなく、 \fIeuid\fP (\fIegid\fP) が実ユーザー (グループ) ID、または実効ユーザー (グループ) ID、
POSIX.1 では、 \fBseteuid\fP() (\fBsetegid\fP()) で、 \fIeuid\fP (\fIegid\fP) として現在の実効ユーザ
(グループ) ID と同じ値を指定可能である 必要はないとされており、いくつかの実装では \fIeuid\fP (\fIegid\fP) として現在の実効ユーザ
(グループ) ID と同じ値を 指定することができない。
-.SS "C library/kernel ABI differences"
-On Linux, \fBseteuid\fP() and \fBsetegid\fP() are implemented as library
-functions that call, respectively, \fBsetreuid\fP(2) and \fBsetresgid\fP(2).
+.SS "C ライブラリとカーネル ABI の違い"
+Linux では、 \fBseteuid\fP() と \fBsetegid\fP() は、それぞれ \fBsetreuid\fP(2) と
+\fBsetresgid\fP(2) を呼び出すライブラリ関数として実装されている。
.SH 関連項目
\fBgeteuid\fP(2), \fBsetresuid\fP(2), \fBsetreuid\fP(2), \fBsetuid\fP(2),
\fBcapabilities\fP(7), \fBcredentials\fP(7), \fBuser_namespaces\fP(7)
.SH エラー
.TP
\fBEINVAL\fP
-The group ID specified in \fIgid\fP is not valid in this user namespace.
+\fIgid\fP で指定されたグループ ID がこのユーザー名前空間では有効ではない。
.TP
\fBEPERM\fP
呼び出し元のプロセスに権限がなく (\fBCAP_SETGID\fP ケーパビリティがなく)、かつ \fIgid\fP が呼び出し元のプロセスの実グループID
側に渡された場合などでは、呼び出し側が \fIfd\fP がどのタイプの名前空間を
参照しているかを知らない可能性がある。)
-\fBCLONE_NEWPID\fP behaves somewhat differently from the other \fInstype\fP
-values: reassociating the calling thread with a PID namespace only changes
-the PID namespace that child processes of the caller will be created in; it
-does not change the PID namespace of the caller itself. Reassociating with
-a PID namespace is only allowed if the PID namespace specified by \fIfd\fP is a
-descendant (child, grandchild, etc.) of the PID namespace of the caller.
-For further details on PID namespaces, see \fBpid_namespaces\fP(7).
+\fBCLONE_NEWPID\fP は他の \fInstype\fP 値の場合と少し違った動作をする。 呼び出し元スレッドを PID 名前空間に関連付けし直すと、
+呼び出し元の子プロセスが作成される PID 名前空間が変更されるだけである。 呼び出し元自身の PID 名前空間は変更されない。 PID
+名前空間を関連付けし直すことができるのは、 \fIfd\fP で指定された PID 名前空間が呼び出し元の PID 名前空間の子孫
+(子プロセス、孫プロセスなど) の場合だけである。 PID 名前空間の詳細は \fBpid_namespaces\fP(7) を参照。
.\" See kernel/user_namespace.c:userns_install() [3.8 source]
.\" commit e66eded8309ebf679d3d3c1f5820d1f2ca332c71
.\" https://lwn.net/Articles/543273/
-A process reassociating itself with a user namespace must have the
-\fBCAP_SYS_ADMIN\fP capability in the target user namespace. Upon successfully
-joining a user namespace, a process is granted all capabilities in that
-namespace, regardless of its user and group IDs. A multithreaded process
-may not change user namespace with \fBsetns\fP(). It is not permitted to use
-\fBsetns\fP() to reenter the caller's current user namespace. This prevents a
-caller that has dropped capabilities from regaining those capabilities via a
-call to \fBsetns\fP(). For security reasons, a process can't join a new user
-namespace if it is sharing filesystem\-related attributes (the attributes
-whose sharing is controlled by the \fBclone\fP(2) \fBCLONE_FS\fP flag) with
-another process. For further details on user namespaces, see
-\fBuser_namespaces\fP(7).
+プロセスが自分自身をユーザー名前空間に再関連付けするには、 そのプロセスは変更後のユーザー名前空間において \fBCAP_SYS_ADMIN\fP
+ケーパビリティを持っていなければならない。 ユーザー名前空間への参加に成功すると、 そのユーザー ID やグループ ID に関わらず、
+プロセスにはその名前空間におけるすべてのケーパビリティが認められる。 マルチスレッドのプロセスは \fBsetns\fP()
+でユーザー名前空間を変更できない。 \fBsetns\fP() を使って、呼び出し元が現在のユーザー名前空間に再度入ることは認められていない。 これにより、
+いくつかのケーパビリティを外した呼び出し元が \fBsetns\fP() を呼び出すことでそれらのケーパビリティを再度得ることを防ぐことができる。
+セキュリティ上の理由から、 ファイルシステム関連の属性 (共有が \fBclone\fP(2) \fBCLONE_FS\fP フラグで制御される属性)
+を別のプロセスと共有している場合、 プロセスは新しいユーザー名前空間に参加できない。 ユーザー名前空間の詳細は
+\fBuser_namespaces\fP(7) を参照。
.\" Above check is in fs/namespace.c:mntns_install() [3.8 source]
-A process may not be reassociated with a new mount namespace if it is
-multithreaded. Changing the mount namespace requires that the caller
-possess both \fBCAP_SYS_CHROOT\fP and \fBCAP_SYS_ADMIN\fP capabilities in its own
-user namespace and \fBCAP_SYS_ADMIN\fP in the target mount namespace. See
-\fBuser_namespaces\fP(7) for details on the interaction of user namespaces and
-mount namespaces.
+プロセスがマルチスレッドの場合、そのプロセスを新しいマウント名前空間に関連付けし直すことは許可されていない。
+マウント名前空間を変更するには、呼び出し元のプロセスが、 自分自身のユーザー名前空間において \fBCAP_SYS_CHROOT\fP と
+\fBCAP_SYS_ADMIN\fP の両方のケーパビリティを持っており、 変更後のマウント名前空間で \fBCAP_SYS_ADMIN\fP
+ケーパビリティを持っていなければならない。 ユーザー名前空間とマウント名前空間の関係の詳細は \fBuser_namespaces\fP(7) を参照。
.SH 返り値
成功すると \fIsetns\fP() は 0 を返す。
失敗すると、 \-1 が返され、 \fIerrno\fP にエラーを示す値が設定される。
スレッドを指定された名前空間に関連付けし直す際に問題が発生した。
.TP
\fBEINVAL\fP
-The caller attempted to join the user namespace in which it is already a
-member.
+自分がすでにメンバーとなっているユーザー名前空間に参加しようとした。
.TP
\fBEINVAL\fP
.\" commit e66eded8309ebf679d3d3c1f5820d1f2ca332c71
-The caller shares filesystem (\fBCLONE_FS\fP) state (in particular, the root
-directory) with other processes and tried to join a new user namespace.
+呼び出し元が他のプロセスとファイルシステム状態 (特に root ディレクトリ) を共有していて (\fBCLONE_FS\fP)、
+新しいユーザー名前空間に参加しようとした。
.TP
\fBEINVAL\fP
.\" See kernel/user_namespace.c::userns_install() [kernel 3.15 sources]
-The caller is multithreaded and tried to join a new user namespace.
+呼び出し元プロセスがマルチスレッドで、新しいユーザー名前空間に参加しようとした。
.TP
\fBENOMEM\fP
指定された名前空間に変更するのに必要なメモリが割り当てられない。
.SH 返り値
成功した場合は 0 が返される。エラーの場合は \-1 が返され、 \fIerrno\fP が適切に設定される。
-\fINote\fP: there are cases where \fBsetresuid\fP() can fail even when the caller
-is UID 0; it is a grave security error to omit checking for a failure return
-from \fBsetresuid\fP().
+\fI注意\fP: 呼び出し元が UID 0 であっても \fBsetresuid\fP() が失敗する場合がある。 \fBsetresuid\fP()
+からのリターンが失敗かどうかの確認を省略することは重大なセキュリティ上のエラーとなる。
.SH エラー
.TP
\fBEAGAIN\fP
-The call would change the caller's real UID (i.e., \fIruid\fP does not match
-the caller's real UID), but there was a temporary failure allocating the
-necessary kernel data structures.
+この呼び出しで呼び出し元の実 UID が変更されるはずだったが (つまり、 \fIruid\fP が呼び出し元の実 UID と一致していない)、
+必要なカーネルのデータ構造体の割り当てで一時的な失敗があった。
.TP
\fBEAGAIN\fP
-\fIruid\fP does not match the caller's real UID and this call would bring the
-number of processes belonging to the real user ID \fIruid\fP over the caller's
-\fBRLIMIT_NPROC\fP resource limit. Since Linux 3.1, this error case no longer
-occurs (but robust applications should check for this error); see the
-description of \fBEAGAIN\fP in \fBexecve\fP(2).
+\fIruid\fP は呼び出し元の実 UID と一致しておらず、 この呼び出しで実ユーザー ID \fIruid\fP に属するプロセス数が呼び出し元の
+\fBRLIMIT_NPROC\fP リソース上限を超過するところであった。 Linux 3.1 以降では、このエラーはもはや発生することはない
+(しかし、堅牢性が求められるアプリケーションではこのエラーを確認すべきである)。 \fBexecve\fP(2) の \fBEAGAIN\fP の説明を参照。
.TP
\fBEINVAL\fP
-One or more of the target user or group IDs is not valid in this user
-namespace.
+対象のユーザー ID やグループ ID のうち 1 つ以上がこのユーザー名前空間で有効ではない。
.TP
\fBEPERM\fP
呼び出したプロセスが特権を持たないのに (\fBCAP_SETUID\fP ケーパビリティを持たないのに)、 ID を許されていない値に変更しようとした。
.SH 返り値
成功した場合は 0 が返される。エラーの場合は \-1 が返され、 \fIerrno\fP が適切に設定される。
-\fINote\fP: there are cases where \fBsetreuid\fP() can fail even when the caller
-is UID 0; it is a grave security error to omit checking for a failure return
-from \fBsetreuid\fP().
+\fI注意\fP: 呼び出し元が UID 0 であっても \fBsetreuid\fP() が失敗する場合がある。 \fBsetreuid\fP()
+からのリターンが失敗かどうかの確認を省略することは重大なセキュリティ上のエラーとなる。
.SH エラー
.TP
\fBEAGAIN\fP
-The call would change the caller's real UID (i.e., \fIruid\fP does not match
-the caller's real UID), but there was a temporary failure allocating the
-necessary kernel data structures.
+この呼び出しで呼び出し元の実 UID が変更されるはずだったが (つまり、 \fIruid\fP が呼び出し元の実 UID と一致していない)、
+必要なカーネルのデータ構造体の割り当てで一時的な失敗があった。
.TP
\fBEAGAIN\fP
-\fIruid\fP does not match the caller's real UID and this call would bring the
-number of processes belonging to the real user ID \fIruid\fP over the caller's
-\fBRLIMIT_NPROC\fP resource limit. Since Linux 3.1, this error case no longer
-occurs (but robust applications should check for this error); see the
-description of \fBEAGAIN\fP in \fBexecve\fP(2).
+\fIruid\fP は呼び出し元の実 UID と一致しておらず、 この呼び出しで実ユーザー ID \fIruid\fP に属するプロセス数が呼び出し元の
+\fBRLIMIT_NPROC\fP リソース上限を超過するところであった。 Linux 3.1 以降では、このエラーはもはや発生することはない
+(しかし、堅牢性が求められるアプリケーションではこのエラーを確認すべきである)。 \fBexecve\fP(2) の \fBEAGAIN\fP の説明を参照。
.TP
\fBEINVAL\fP
-One or more of the target user or group IDs is not valid in this user
-namespace.
+対象のユーザー ID やグループ ID のうち 1 つ以上がこのユーザー名前空間で有効ではない。
.TP
\fBEPERM\fP
呼び出し元のプロセスに特権がなく (Linux では \fBsetreuid\fP() の場合に \fBCAP_SETUID\fP ケーパビリティ
.br
.ad b
.SH 説明
-\fBsetsid\fP() creates a new session if the calling process is not a process
-group leader. The calling process is the leader of the new session (i.e.,
-its session ID is made the same as it process ID). The calling process also
-becomes the process group leader of a new process group in the session
-(i.e., its process group ID is made the same as it process ID).
+\fBsetsid\fP() は、 呼び出したプロセスがプロセスグループ・リーダー (process group leader) でなければ、
+新しいセッションを作成する。 呼び出したプロセスは、 新しいセッションのリーダーとなる (すなわち、そのセッション ID がプロセス ID
+と同じ値になる)。 また、呼び出したプロセスは、 そのセッションの新しいプロセスグループのプロセスグループ・リーダーにもなる
+(すなわち、プロセスグループ ID がプロセス ID と同じ値になる)。
-The calling process will be the only process in the new process group and in
-the new session. The new session has no controlling terminal.
+呼び出したプロセスは、 新しいプロセスグループと新しいセッションの唯一のプロセスとなる。 新しいセッションは制御端末を持たない。
.SH 返り値
成功すると、呼び出したプロセスの (新しい) セッション ID が返される。 エラーの場合は、 \fI(pid_t)\ \-1\fP が返され、
\fIerrno\fP にエラーを示す値が設定される。
\fBfork\fP(2) で作成された子プロセスは、親プロセスのセッション ID を継承する。 \fBexecve\fP(2) の前後でセッション ID
は保存される。
-A process group leader is a process whose process group ID equals its PID.
-Disallowing a process group leader from calling \fBsetsid()\fP prevents the
-possibility that a process group leader places itself in a new session while
-other processes in the process group remain in the original session; such a
-scenario would break the strict two\-level hierarchy of sessions and process
-groups. In order to be sure that \fBsetsid\fP() will succeed, \fBfork\fP(2) and
-\fB_exit\fP(2), and have the child do \fBsetsid\fP().
+プロセスグループ・リーダーは、 プロセスグループ ID がその PID と同じ値のプロセスである。 プロセスグループ・リーダーが \fBsetsid\fP()
+を呼び出すことを許可しないと、 そのプロセスグループ内の他のプロセスを元のセッションに残したまま、
+プロセスグループ・リーダーが自分自身を新しいセッションに入れるということができなくなる。 このようなシナリオは、
+セッションとプロセスグループという厳密な 2 階層モデルを壊すことになる。 \fBsetsid\fP() が成功することを保証するには、 \fBfork\fP(2)
+と \fB_exit\fP(2) を行い、 その子プロセスに \fBsetsid\fP() をさせればよい。
.SH 関連項目
\fBsetsid\fP(1), \fBgetsid\fP(2), \fBsetpgid\fP(2), \fBsetpgrp\fP(2), \fBtcgetsid\fP(3),
\fBcredentials\fP(7)
.SH 返り値
成功した場合は 0 が返される。エラーの場合は \-1 が返され、 \fIerrno\fP が適切に設定される。
-\fINote\fP: there are cases where \fBsetuid\fP() can fail even when the caller is
-UID 0; it is a grave security error to omit checking for a failure return
-from \fBsetuid\fP().
+\fI注意\fP: 呼び出し元が UID 0 であっても \fBsetuid\fP() が失敗する場合がある。 \fBsetuid\fP()
+からのリターンが失敗かどうかの確認を省略することは重大なセキュリティ上のエラーとなる。
.SH エラー
.TP
\fBEAGAIN\fP
-The call would change the caller's real UID (i.e., \fIuid\fP does not match the
-caller's real UID), but there was a temporary failure allocating the
-necessary kernel data structures.
+この呼び出しで呼び出し元の実 UID が変更されるはずだったが (つまり、 \fIuid\fP が呼び出し元の実 UID と一致していない)、
+必要なカーネルのデータ構造体の割り当てで一時的な失敗があった。
.TP
\fBEAGAIN\fP
-\fIuid\fP does not match the real user ID of the caller and this call would
-bring the number of processes belonging to the real user ID \fIuid\fP over the
-caller's \fBRLIMIT_NPROC\fP resource limit. Since Linux 3.1, this error case
-no longer occurs (but robust applications should check for this error); see
-the description of \fBEAGAIN\fP in \fBexecve\fP(2).
+\fIuid\fP は呼び出し元の実 UID と一致しておらず、 この呼び出しで実ユーザー ID \fIruid\fP に属するプロセス数が呼び出し元の
+\fBRLIMIT_NPROC\fP リソース上限を超過するところであった。 Linux 3.1 以降では、このエラーはもはや発生することはない
+(しかし、堅牢性が求められるアプリケーションではこのエラーを確認すべきである)。 \fBexecve\fP(2) の \fBEAGAIN\fP の説明を参照。
.TP
\fBEINVAL\fP
-The user ID specified in \fIuid\fP is not valid in this user namespace.
+\fIuid\fP で指定されたユーザー ID がこのユーザー名前空間では有効ではない。
.TP
\fBEPERM\fP
ユーザーが特権を持たず (Linux では \fBCAP_SETUID\fP ケーパビリティ (capability) を持たず)、 \fIuid\fP
これらのシステムコールは常に成功する。
.SH バージョン
.\" f6187769dae48234f3877df3c4d99294cc2254fa
-Since Linux 3.16, support for these system calls is optional, depending on
-whether the kernel was built with the \fBCONFIG_SGETMASK_SYSCALL\fP option.
+Linux 3.16 以降では、これらのシステムコールのサポートは任意となり、利用できるかはカーネルが
+\fBCONFIG_SGETMASK_SYSCALL\fP オプションを有効にしてコンパイルされているかに依存する。
.SH 準拠
これらのシステムコールは Linux 固有である。
.SH 注意
.\"
\fBIPC_PRIVATE\fP はフラグではなく \fIkey_t\fP 型である。 この特別な値が \fIkey\fP に使用された場合は、 \fBshmget\fP()
は \fIshmflg\fP の下位 9 ビットを除いた全てを無視し、 新しい共有メモリ・セグメントを作成する。
-.SS "Shared memory limits"
+.SS 共有メモリの上限
\fBshmget\fP() コールに影響する共有メモリ・セグメント資源の制限は以下の通りである:
.TP
\fBSHMALL\fP
ULONG_MAX \- 2^24
-The effect of this value (which is suitable for both 32\-bit and 64\-bit
-systems) is to impose no limitation on allocations. This value, rather
-than \fBULONG_MAX\fP, was chosen as the default to prevent some cases where
-historical applications simply raised the existing limit without first
-checking its current value. Such applications would cause the value to
-overflow if the limit was set at \fBULONG_MAX\fP.
+この値は割り当てに関する上限としては適用されない (なお、この値は 32 ビットシステムにも 64 ビットシステムにも適したものになっている)。
+\fBULONG_MAX\fP ではなく、この値が選ばれたのは、
+古いアプリケーションが最初に現在の値を確認せずに既存の上限をそのまま増やしてしまっても問題が起こらないようなデフォルト値を選んだからである。
+このようなアプリケーションでは、 上限を \fBULONG_MAX\fP に設定すると値がオーバーフローしてしまうことになる。
-From Linux 2.4 up to Linux 3.15, the default value for this limit was:
+Linux 2.4 から Linux 3.15 では、この上限のデフォルト値は以下であった。
SHMMAX / PAGE_SIZE * (SHMMNI / 16)
-If \fBSHMMAX\fP and \fBSHMMNI\fP were not modified, then multiplying the result of
-this formula by the page size (to get a value in bytes) yielded a value of 8
-GB as the limit on the total memory used by all shared memory segments.
+\fBSHMMAX\fP と \fBSHMMNI\fP が変更されないとすると、 この式の結果に (バイト単位の値を得るために) ページサイズを掛け算すると、
+全ての共有メモリセグメントで使用される全メモリの上限として、 8 GB という値が得られる。
.TP
\fBSHMMAX\fP
1 つの共有メモリセグメントの最大サイズ (バイト数)。
ULONG_MAX \- 2^24
-The effect of this value (which is suitable for both 32\-bit and 64\-bit
-systems) is to impose no limitation on allocations. See the description of
-\fBSHMALL\fP for a discussion of why this default value (rather than
-\fBULONG_MAX\fP) is used.
+この値は割り当てに関する上限としては適用されない (なお、この値は 32 ビットシステムにも 64 ビットシステムにも適したものになっている)。
+(\fBULONG_MAX\fP ではなく) このデフォルト値が使われている理由については \fBSHMALL\fP の説明を参照。
Linux 2.2 から Linux 3.15 までは、この上限値のデフォルト値は 0x2000000 (32MB) であった。
-Because it is not possible to map just part of a shared memory segment, the
-amount of virtual memory places another limit on the maximum size of a
-usable segment: for example, on i386 the largest segments that can be mapped
-have a size of around 2.8 GB, and on x86_64 the limit is around 127 TB.
+共有メモリセグメントの一部分だけをマッピングすることはできないので、 使用可能なセグメントの最大サイズには仮想メモリの総量という別の上限が適用される。
+例えば、i386 ではマッピング可能な最大セグメントの大きさはおおよそ 2.8GB で、 x86_64 では上限はおおよそ 127TB である。
.TP
\fBSHMMIN\fP
共有メモリ・セグメントのバイト単位の大きさの下限: 実装依存 (現在は 1 バイトだが、実質的な最小サイズは \fBPAGE_SIZE\fP である)。
.IP *
その他の場合は \fIshmaddr\fP は付加を行なうアドレスで、ページ境界を指している必要がある。
.PP
-In addition to \fBSHM_RND\fP, the following flags may be specified in the
-\fIshmflg\fP bit\-mask argument:
+\fBSHM_RND\fP に加えて、以下のフラグを \fIshmflg\fP ビットマスク引き数に指定できる。
.TP
\fBSHM_EXEC\fP (Linux 固有; Linux 2.6.9 以降)
-Allow the contents of the segment to be executed. The caller must have
-execute permission on the segment.
+セグメントの内容を実行できる。 呼び出し元はセグメントに対する実行許可を持っていなければならない。
.TP
\fBSHM_RDONLY\fP
セグメントを読み込み専用に付加する。 プロセスはそのセグメントへの読み込み許可を持っていなければならない。
以下のシステム・パラメーターは、 \fBshmat\fP() に影響する:
.TP
\fBSHMLBA\fP
-Segment low boundary address multiple. When explicitly specifying an attach
-address in a call to \fBshmat\fP(), the caller should ensure that the address
-is a multiple of this value. This is necessary on some architectures, in
-order either to ensure good CPU cache performance or to ensure that
-different attaches of the same segment have consistent views within the CPU
-cache. \fBSHMLBA\fP is normally some multiple of the system page size (on many
-Linux architectures, it is the same as the system page size).
+セグメントの下限アドレス倍数 (Segment low boundary address multiple)。 \fBshmat\fP()
+の呼び出しにおいて付加するアドレスを明示的に指定する際、 呼び出し元は指定するアドレスがこの値の倍数になるように保証しなければならない。
+これはいくつかのアーキテクチャーでは必要なことで、 CPU キャッシュの性能を保証するためであったり、 同じセグメントの別の付与を CPU
+キャッシュ内部で一貫して扱えるようにするためだったりする。 \fBSHMLBA\fP は通常はシステムページサイズの倍数である (Linux
+の多くのアーキテクチャーではシステムページサイズと同じである)。
.PP
現在の実装では、プロセスごとの 共有メモリ・セグメントの最大数 (\fBSHMSEG\fP) に関する実装依存の制限はない。
.SH 関連項目
アーキテクチャによっては共用体 (union) が用いられており、その場合には \fIsa_handler\fP と \fIsa_sigaction\fP
の両方を同時に割り当てることはできない。
.PP
-The \fIsa_restorer\fP field is not intended for application use. (POSIX does
-not specify a \fIsa_restorer\fP field.) Some further details of purpose of
-this field can be found in \fBsigreturn\fP(2).
+\fIsa_restorer\fP はアプリケーションが使用することを意図したフィールドではない (POSIX は \fIsa_restorer\fP
+フィールドを規定していない)。 このフィールドの詳細な目的については \fBsigreturn\fP(2) に書かれている。
.PP
\fIsa_handler\fP は \fIsignum\fP に対応する動作を指定するもので、 デフォルトの動作を行う \fBSIG_DFL\fP、
そのシグナルを無視する \fBSIG_IGN\fP、 シグナルハンドラ関数へのポインタが設定できる。
このフラグはシグナルハンドラを設定する際にのみ意味を持つ。 \fBsignal\fP(7) に書かれているシステムコールの再開に関する議論を参照のこと。
.TP
\fBSA_RESTORER\fP
-\fINot intended for application use\fP. This flag is used by C libraries to
-indicate that the \fIsa_restorer\fP field contains the address of a "signal
-trampoline". See \fBsigreturn\fP(2) for more details.
+\fIアプリケーションでの使用を意図したものではない\fP。 このフラグは C ライブラリが \fIsa_restorer\fP フィールドに "signal
+trampoline" のアドレスが入っていることを示すために使用される。 詳細は \fBsigreturn\fP(2) を参照。
.TP
\fBSA_SIGINFO\fP (Linux 2.2 以降)
.\" (The
.SS "C ライブラリとカーネル ABI の違い"
Linux では、 \fBsigwaitinfo\fP() は \fBsigtimedwait\fP() を用いて実装されたライブラリ関数である。
-The raw \fBsigtimedwait\fP() system call has a fifth argument, \fIsize_t
-sigsetsize\fP, which specifies the size in bytes of the \fIset\fP argument. The
-glibc \fBsigtimedwait\fP() wrapper function specifies this argument as a fixed
-value (equal to \fIsizeof(sigset_t)\fP).
+素の \fBsigtimedwait\fP() システムコールは 5 番目の引き数 \fIsize_t sigsetsize\fP を取る。 この引き数は
+\fIset\fP 引き数のバイト単位のサイズを指定する。 glibc の \fBsigtimedwait\fP() のラッパー関数はこの引き数に固定値
+(\fIsizeof(sigset_t)\fP と同じ) を指定する。
.SH 関連項目
\fBkill\fP(2), \fBsigaction\fP(2), \fBsignal\fP(2), \fBsignalfd\fP(2), \fBsigpending\fP(2),
\fBsigprocmask\fP(2), \fBsigqueue\fP(3), \fBsigsetops\fP(3), \fBsigwait\fP(3),
ファイルディスクリプタ \fIfd_in\fP からファイルディスクリプタ \fIfd_out\fP へ最大 \fIlen\fP バイトを転送する。 2
つのファイルディスクリプタのうち一つは パイプを参照していなければならない。
-The following semantics apply for \fIfd_in\fP and \fIoff_in\fP:
+\fIfd_in\fP と \fIoff_in\fP には以下のルールが適用される。
.IP * 3
-If \fIfd_in\fP refers to a pipe, then \fIoff_in\fP must be NULL.
+\fIfd_in\fP がパイプを参照している場合、 \fIoff_in\fP は NULL でなければならない。
.IP *
-If \fIfd_in\fP does not refer to a pipe and \fIoff_in\fP is NULL, then bytes are
-read from \fIfd_in\fP starting from the current file offset, and the current
-file offset is adjusted appropriately.
+\fIfd_in\fP がパイプを参照しておらず、かつ \fIoff_in\fP が NULL の場合、 バイトは \fIfd_in\fP
+の現在のファイルオフセットから読み出され、 現在のファイルオフセットは適切に調整される。
.IP *
-If \fIfd_in\fP does not refer to a pipe and \fIoff_in\fP is not NULL, then
-\fIoff_in\fP must point to a buffer which specifies the starting offset from
-which bytes will be read from \fIfd_in\fP; in this case, the current file
-offset of \fIfd_in\fP is not changed.
+\fIfd_in\fP がパイプを参照しておらず、 \fIoff_in\fP が NULL でない場合、 \fIoff_in\fP は \fIfd_in\fP
+からのデータ読み出しを開始する先頭オフセットを格納したバッファ へのポインタでなければならない。この場合、 \fIfd_in\fP
+の現在のファイルオフセットは変更されない。
.PP
-Analogous statements apply for \fIfd_out\fP and \fIoff_out\fP.
+\fIfd_out\fP と \fIoff_out\fP に関しても同様である。
\fIflags\fP 引き数には、以下の値の 0 個以上をビット毎の論理和の形で指定する。
.TP 1.9i
.SH エラー
.TP
\fBEAGAIN\fP
-\fBSPLICE_F_NONBLOCK\fP was specified in \fIflags\fP, and the operation would
-block.
+\fBSPLICE_F_NONBLOCK\fP が \fIflags\fP に指定されていて、かつ操作が停止するような状態であった。
.TP
\fBEBADF\fP
ファイルディスクリプタの一方または両方が有効ではない、 もしくは適切な read\-write モードではない。
.fi
.in
.PP
-Most of these MAGIC constants are defined in \fI/usr/include/linux/magic.h\fP
-some are hardcoded in kernel sources.
+これらの MAGIC 定数のほとんどは \fI/usr/include/linux/magic.h\fP
+で定義されており、いくつかはカーネルソースで直接書かれている。
.PP
\fIf_fsid\fP にどんな値が入るべきなのかは誰も知らない (但し、下記を参照)。
.PP
.SH バグ
.\" broken in commit ff0c7d15f9787b7e8c601533c015295cc68329f8
.\" fixed in commit d70ef97baf048412c395bb5d65791d8fe133a52b
-From Linux 2.6.38 up to and including Linux 3.1, \fBfstatfs\fP() failed with
-the error \fBENOSYS\fP for file descriptors created by \fBpipe\fP(2).
+Linux 2.6.38 から Linux 3.1 までは (3.1 を含む)、 \fBfstatfs\fP() は \fBpipe\fP(2)
+で作成されたファイルディスクリプタに対してはエラー \fBENOSYS\fP で失敗していた。
.SH 関連項目
\fBstat\fP(2), \fBstatvfs\fP(2), \fBpath_resolution\fP(7)
.SH この文書について
\fInewdirfd\fP が有効なファイルディスクリプタでない。
.TP
\fBENOENT\fP
-\fIlinkpath\fP is a relative pathname and \fInewdirfd\fP refers to a directory
-that has been deleted.
+\fIlinkpath\fP が相対パス名で、 \fInewdirfd\fP が削除されたディレクトリを参照している。
.TP
\fBENOTDIR\fP
\fIlinkpath\fP が相対パスで、 \fInewdirfd\fP がディレクトリ以外のファイルを参照しているファイルディスクリプタである。
シンボリックリンクによって参照される名前を削除すると (それが他にハードリンク (hard link) を持たなければ) 実際にファイルが削除される。
この動作が望んだものでない場合は、 \fBlink\fP(2) を使用すること。
.SS "glibc での注意"
-On older kernels where \fBsymlinkat\fP() is unavailable, the glibc wrapper
-function falls back to the use of \fBsymlink\fP(2). When \fIlinkpath\fP is a
-relative pathname, glibc constructs a pathname based on the symbolic link in
-\fI/proc/self/fd\fP that corresponds to the \fInewdirfd\fP argument.
+\fBsymlinkat\fP() が利用できない古いカーネルでは、 glibc ラッパー関数は \fBsymlink\fP(2)
+を使用するモードにフォールバックする。 \fIpathname\fP が相対パスの場合、 glibc は \fInewdirfd\fP 引き数に対応する
+\fI/proc/self/fd\fP のシンボリックリンクに基づいてパス名を構成する。
.SH 関連項目
\fBln\fP(1), \fBlchown\fP(2), \fBlink\fP(2), \fBlstat\fP(2), \fBopen\fP(2), \fBreadlink\fP(2),
\fBrename\fP(2), \fBunlink\fP(2), \fBpath_resolution\fP(7), \fBsymlink\fP(7)
.SH エラー
.TP
\fBEAGAIN\fP
-\fBSPLICE_F_NONBLOCK\fP was specified in \fIflags\fP, and the operation would
-block.
+\fBSPLICE_F_NONBLOCK\fP が \fIflags\fP に指定されていて、かつ操作が停止するような状態であった。
.TP
\fBEINVAL\fP
\fIfd_in\fP と \fIfd_out\fP のどちらかがパイプを参照していない。もしくは \fIfd_in\fP と \fIfd_out\fP
\fBunlinkat\fP(): POSIX.1\-2008.
.SH 注意
.SS "glibc での注意"
-On older kernels where \fBunlinkat\fP() is unavailable, the glibc wrapper
-function falls back to the use of \fBunlink\fP(2) or \fBrmdir\fP(2). When
-\fIpathname\fP is a relative pathname, glibc constructs a pathname based on the
-symbolic link in \fI/proc/self/fd\fP that corresponds to the \fIdirfd\fP argument.
+\fBunlinkat\fP() が利用できない古いカーネルでは、 glibc ラッパー関数は \fBunlink\fP(2) と \fBrmdir\fP(2)
+を使用するモードにフォールバックする。 \fIpathname\fP が相対パスの場合、 glibc は \fIdirfd\fP 引き数に対応する
+\fI/proc/self/fd\fP のシンボリックリンクに基づいてパス名を構成する。
.SH バグ
NFS プロトコルに内在する問題により、まだ使用中のファイルが想定外に消えてしまうことがありえる。
.SH 関連項目
ケーパビリティが必要である。
.TP
\fBCLONE_NEWPID\fP (Linux 3.8 以降)
-This flag has the same effect as the \fBclone\fP(2) \fBCLONE_NEWPID\fP flag.
-Unshare the PID namespace, so that the calling process has a new PID
-namespace for its children which is not shared with any previously existing
-process. The calling process is \fInot\fP moved into the new namespace. The
-first child created by the calling process will have the process ID 1 and
-will assume the role of \fBinit\fP(1) in the new namespace. \fBCLONE_NEWPID\fP
-automatically implies \fBCLONE_THREAD\fP as well. Use of \fBCLONE_NEWPID\fP
-requires the \fBCAP_SYS_ADMIN\fP capability. For further information, see
-\fBpid_namespaces\fP(7).
+このフラグは \fBclone\fP(2) \fBCLONE_NEWPID\fP フラグと同じ効果を持つ。 PID 名前空間を共有しない。 呼び出し元プロセスは、
+すでに存在するどのプロセスとも共有されない新しい PID 名前空間を、 自身の子プロセス用に持つことになる。
+このプロセスにより作成される最初の子プロセスはプロセス ID 1 を持ち、 この新しい名前空間において \fBinit\fP(1) の役割を持つとみなされる。
+\fBCLONE_NEWPID\fP を指定すると、自動的に \fBCLONE_THREAD\fP も指定されたものとみなされる。 \fBCLONE_NEWPID\fP
+を使用するには \fBCAP_SYS_ADMIN\fP ケーパビリティが必要である。 詳細な情報は \fBpid_namespaces\fP(7) を参照。
.TP
\fBCLONE_NEWUSER\fP (Linux 3.8 以降)
-This flag has the same effect as the \fBclone\fP(2) \fBCLONE_NEWUSER\fP flag.
-Unshare the user namespace, so that the calling process is moved into a new
-user namespace which is not shared with any previously existing process. As
-with the child process created by \fBclone\fP(2) with the \fBCLONE_NEWUSER\fP
-flag, the caller obtains a full set of capabilities in the new namespace.
+このフラグは \fBclone\fP(2) \fBCLONE_NEWUSER\fP フラグと同じ効果を持つ。 ユーザー名前空間を共有せず、
+呼び出し元プロセスはすでに存在するどのプロセスとも共有されない新しいユーザー名前空間に移動される。 \fBCLONE_NEWUSER\fP フラグを指定して
+\fBclone\fP(2) で作成された子プロセスと同様に、 呼び出し元は新しい名前空間ですべてのケーパビリティを獲得する。
.IP
.\" commit e66eded8309ebf679d3d3c1f5820d1f2ca332c71
.\" https://lwn.net/Articles/543273/
-\fBCLONE_NEWUSER\fP requires that the calling process is not threaded;
-specifying \fBCLONE_NEWUSER\fP automatically implies \fBCLONE_THREAD\fP. Since
-Linux 3.9, \fBCLONE_NEWUSER\fP also automatically implies \fBCLONE_FS\fP.
-\fBCLONE_NEWUSER\fP requires that the user ID and group ID of the calling
-process are mapped to user IDs and group IDs in the user namespace of the
-calling process at the time of the call.
+\fBCLONE_NEWUSER\fP を使うには、呼び出し元プロセスがスレッド化されていないことが必要である。 \fBCLONE_NEWUSER\fP
+を指定すると、自動的に \fBCLONE_THREAD\fP が指定されたものとみなされる。 Linux 3.9 以降では、 \fBCLONE_NEWUSER\fP
+が指定された場合 \fBCLONE_FS\fP も指定されたとみなされる。 \fBCLONE_NEWUSER\fP を使うには、呼び出し元プロセスのユーザー ID
+とグループ ID が、 呼び出した時点で、 呼び出し元プロセスのユーザー名前空間のユーザー ID とグループ ID にマッピングされている必要がある。
-For further information on user namespaces, see \fBuser_namespaces\fP(7).
+ユーザー名前空間の詳細は \fBuser_namespaces\fP(7) を参照。
.TP
\fBCLONE_NEWUTS\fP (Linux 2.6.19 以降)
このフラグは \fBclone\fP(2) \fBCLONE_NEWUTS\fP フラグと同じ効果を持つ。 UTS
.\" commit 9edff4ab1f8d82675277a04e359d0ed8bf14a7b7
.\" CLONE_NEWNS If CLONE_SIGHAND is set and signals are also being shared
.\" (i.e., current->signal->count > 1), force CLONE_THREAD.
-This flag reverses the effect of the \fBclone\fP(2) \fBCLONE_SYSVSEM\fP flag.
-Unshare System\ V semaphore adjustment (\fIsemadj\fP) values, so that the
-calling process has a new empty \fIsemadj\fP list that is not shared with any
-other process. If this is the last process that has a reference to the
-process's current \fIsemadj\fP list, then the adjustments in that list are
-applied to the corresponding semaphores, as described in \fBsemop\fP(2).
+このフラグは \fBclone\fP(2) \fBCLONE_SYSVSEM\fP フラグの効果を逆転させる。 System\ V セマフォの調整値
+(\fIsemadj\fP) を共有せず、 呼び出し元プロセスは他のプロセスとは共有されない新しい空の \fIsemadj\fP リストを持つ。
+そのプロセスが、自分の現在の \fIsemadj\fP リストへの参照を持つ最後のプロセスであれば、 このリストの調整値は対応するセマフォに適用される
+(\fBsemop\fP(2) に説明がある通り)。
.PP
.\" As at 3.9, the following forced implications also apply,
.\" although the relevant flags are not yet implemented.
.\" If CLONE_VM is set, force CLONE_SIGHAND.
.\"
.\" See kernel/fork.c::check_unshare_flags()
-In addition, \fBCLONE_THREAD\fP, \fBCLONE_SIGHAND\fP, and \fBCLONE_VM\fP can be
-specified in \fIflags\fP if the caller is single threaded (i.e., it is not
-sharing its address space with another process or thread). In this case,
-these flags have no effect. (Note also that specifying \fBCLONE_THREAD\fP
-automatically implies \fBCLONE_VM\fP, and specifying \fBCLONE_VM\fP automatically
-implies \fBCLONE_SIGHAND\fP.) If the process is multithreaded, then the use of
-these flags results in an error.
+上記に加えて、 呼び出し元がシングルスレッドの場合 (すなわち別のプロセスやスレッドとアドレス空間を共有していない場合)、
+\fBCLONE_THREAD\fP, \fBCLONE_SIGHAND\fP, \fBCLONE_VM\fP を指定することができる。 この場合、
+これらのフラグは効果を持たない。 (\fBCLONE_THREAD\fP を指定すると自動的に \fBCLONE_VM\fP が指定されたとみなされ、
+\fBCLONE_VM\fP を指定すると自動的に \fBCLONE_SIGHAND\fP が指定されたとみなされる点に注意してほしい。)
+プロセスがマルチスレッドの場合、 これらのフラグを使用するとエラーとなる。
.PP
\fIflags\fP に 0 が指定された場合、 \fBunshare\fP() は何も行わないので、
呼び出し元プロセスの実行コンテキストは、何も変更されない。
\fIflags\fP に不正なビットが指定された。
.TP
\fBEINVAL\fP
-\fBCLONE_THREAD\fP, \fBCLONE_SIGHAND\fP, or \fBCLONE_VM\fP was specified in \fIflags\fP,
-and the caller is multithreaded.
+\fBCLONE_THREAD\fP, \fBCLONE_SIGHAND\fP, \fBCLONE_VM\fP が \fIflags\fP に指定されたが、
+呼び出したプロセスはマルチスレッドである。
.TP
\fBENOMEM\fP
呼び出し元のコンテキストのうち共有を解除する必要がある部分をコピーするために、 十分なメモリが確保できなかった。
呼び出し元プロセスはこの操作を行うのに必要な特権を持っていなかった。
.TP
\fBEPERM\fP
-\fBCLONE_NEWUSER\fP was specified in \fIflags\fP, but either the effective user ID
-or the effective group ID of the caller does not have a mapping in the
-parent namespace (see \fBuser_namespaces\fP(7)).
+\fBCLONE_NEWUSER\fP が \fIflags\fP に指定されたが、 呼び出し元の実効ユーザー ID もしくは実効グループ ID
+が親名前空間にマッピングがない (\fBuser_namespaces\fP(7) 参照)。
.TP
\fBEPERM\fP (Linux 3.9 以降)
.\" commit 3151527ee007b73a0ebd296010f1c0454a919c7d
.\" FIXME What is the rationale for this restriction?
-\fBCLONE_NEWUSER was specified in\fP \fIflags\fP and the caller is in a chroot
-environment (i.e., the caller's root directory does not match the root
-directory of the mount namespace in which it resides).
+\fBCLONE_NEWUSER\fP が \fIflags\fP に指定され、 呼び出し元が chroot された環境にいる (すなわち、呼び出し元の root
+ディレクトリが呼び出し元が属するマウント名前空間の root ディレクトリに一致しない)。
.TP
\fBEUSERS\fP (Linux 3.11 以降)
-\fBCLONE_NEWUSER\fP was specified in \fIflags\fP, and the call would cause the
-limit on the number of nested user namespaces to be exceeded. See
-\fBuser_namespaces\fP(7).
+\fBCLONE_NEWUSER\fP が \fIflags\fP に指定されており、 この呼び出しによりネストされたユーザー名前空間数の上限を超えてしまう。
+\fBuser_namespaces\fP(7) を参照。
.SH バージョン
\fBunshare\fP() システムコールは Linux カーネル 2.6.16 で追加された。
.SH 準拠
\fBCLONE_THREAD\fP, \fBCLONE_VM\fP の効果を取り消すためのフラグが実装されていない。
これらの機能は、必要であれば将来追加されるかもしれない。
.SH 例
-The program below provides a simple implementation of the \fBunshare\fP(1)
-command, which unshares one or more namespaces and executes the command
-supplied in its command\-line arguments. Here's an example of the use of
-this program, running a shell in a new mount namespace, and verifying that
-the original shell and the new shell are in separate mount namespaces:
+以下のプログラムは \fBunshare\fP(1) コマンドの簡単な実装である。 このコマンドは、1 つ以上の名前空間の unshare を行ってから、
+コマンドライン引き数で指定されたコマンドを実行する。 以下はこのプログラムの使用例である。 新しいマウント名前空間でシェルを実行し、
+元のシェルと新しいシェルが別のマウント名前空間にいることを確認している。
.in +4n
.nf
.fi
.in
-The differing output of the two \fBreadlink\fP(1) commands shows that the two
-shells are in different mount namespaces.
+2 つの \fBreadlink\fP(1) コマンドの出力が違うことから、 2 つのシェルは異なるマウント名前空間にいることが分かる。
.SS プログラムのソース
\&
.nf
.SH エラー
.TP
\fBEAGAIN\fP
-\fBSPLICE_F_NONBLOCK\fP was specified in \fIflags\fP, and the operation would
-block.
+\fBSPLICE_F_NONBLOCK\fP が \fIflags\fP に指定されていて、かつ操作が停止するような状態であった。
.TP
\fBEBADF\fP
\fIfd\fP が有効でない、もしくはパイプを参照していない。
.fi
.in
.SH 属性
-For an explanation of the terms used in this section, see \fBattributes\fP(7).
+この節で使用されている用語の説明は \fBattributes\fP(7) を参照のこと。
.ad l
.TS
allbox;
と同一の機能を持つ (\fBfseek\fP(3) を見よ) が、ただし \fBfseeko\fP() 関数の \fIoffset\fP 引数と
\fBftello\fP() の返り値が、 \fIlong\fP ではなく \fIoff_t\fP になっている。
.LP
-On some architectures, both \fIoff_t\fP and \fIlong\fP are 32\-bit types, but
-defining \fB_FILE_OFFSET_BITS\fP with the value 64 (before including \fIany\fP
-header files) will turn \fIoff_t\fP into a 64\-bit type.
+いくつかのアーキテクチャーでは、 \fIoff_t\fP と \fIlong\fP の両方が 32 ビット型だが、
+(「どの」ヘッダーファイルをインクルードするよりも前に) \fB_FILE_OFFSET_BITS\fP を値 64 で定義すると、 \fIoff_t\fP が
+64 ビット型になる。
.SH 返り値
成功した場合、 \fBfseeko\fP() は 0 を、 \fBftello\fP() は現在のオフセットを返す。 失敗した場合、\-1 を返し、
\fIerrno\fP にエラーを示す値をセットする。
.SH 準拠
SUSv2, POSIX.1\-2001.
.SH 注意
-These functions are found on System V\-like systems.
+これらの関数は System\-V 風のシステムに存在する。
.SH 関連項目
\fBfseek\fP(3)
.SH この文書について
.RE
.TP
\fBFTW_CHDIR\fP
-If set, do a \fBchdir\fP(2) to each directory before handling its contents.
-This is useful if the program needs to perform some action in the directory
-in which \fIfpath\fP resides. (Specifying this flag has no effect on the
-pathname that is passed in the \fIfpath\fP argument of \fIfn\fP.)
+セットされると、ディレクトリの内容を処理する前に そのディレクトリに \fBchdir\fP(2) する。このフラグは、 \fIfpath\fP
+が属すディレクトリで何らかの動作を実行する必要がある場合に 便利である。
+(このフラグを指定しても \fIfn\fP の \fIfpath\fP 引き数で渡されるパス名には影響しない。)
.TP
\fBFTW_DEPTH\fP
セットされると、帰りがけ順探索 (post\-order traversal) を行う。 つまり、ディレクトリそのものを引き数とした \fIfn\fP()
.SH エラー
.TP
\fBEAGAIN\fP
-The service was temporarily unavailable; try again later. For NSS backends
-in glibc this indicates a temporary error talking to the backend. The error
-may correct itself, retrying later is suggested.
+サービスが一時的に利用できなかったこと。あとでもう一度試してほしい。 NSS バックエンドの場合、glibc
+では、バックエンドとの通信中に一時的なエラーが発生したことを示す。 このエラーは直るかもしれないので、あとでもう一度試すよう提案している。
.TP
\fBEINTR\fP
シグナルが捕捉された。
.TP
.\" not in POSIX
\fBENOENT\fP
-A necessary input file cannot be found. For NSS backends in glibc this
-indicates the backend is not correctly configured.
+必要な入力ファイルが見つからなかった。 NSS バックエンドの場合、glibc では、このエラーはバックエンドが正しく設定されていないことを示す。
.TP
\fBENOMEM\fP
.\" not in POSIX
前者は、最近のバージョンの BIND のヘッダファイル \fI<arpa/nameser.h>\fP 中の定数 \fBMAXDNAME\fP
と同じ値である。 後者は、割り当て済の数値について記した現在の RFC に 列挙されてサービスから推量した値である。
-Before glibc version 2.2, the \fIhostlen\fP and \fIservlen\fP arguments were typed
-as \fIsize_t\fP.
+glibc バージョン 2.2 より前では、 引き数 \fIhostlen\fP, \fIservlen\fP の型は \fIsize_t\fP であった。
.SH 例
以下のコードは、指定されたソケットアドレスに対する ホストとサービスの数値表式を取得しようと試みる。 特定のアドレスファミリーに対する参照情報は
一切ハードコードされていないことに着目してほしい。
--- /dev/null
+.\" Copyright (C) 2014, Michael Kerrisk <mtk.manpages@gmail.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 GROUP_MEMBER 3 2014\-03\-30 GNU "Linux Programmer's Manual"
+.SH 名前
+group_member \- プロセスがグループに属しているかを検査する
+.SH 書式
+\fB#include <unistd.h>\fP
+.sp
+\fBint group_member(gid_t \fP\fIgid\fP\fB);\fP
+.sp
+.in -4n
+glibc 向けの機能検査マクロの要件 (\fBfeature_test_macros\fP(7) 参照):
+.in
+.sp
+\fBgroup_member\fP(): _GNU_SOURCE
+.SH 説明
+\fBgroup_member\fP() 関数は、 呼び出し元の補助グループ ID (\fBgetgroups\fP(2) が返す値) のいずれかが \fIgid\fP
+に一致するかを検索する。
+.SH 返り値
+\fBgroup_member\fP() 関数は、 呼び出し元の補助グループ ID のいずれかが \fIgid\fP に一致すれば 0 以外の値を、そうでなければ
+0 を返す。
+.SH 準拠
+この関数は非標準の GNU 拡張である。
+.SH 関連項目
+\fBgetgid\fP(2), \fBgetgroups\fP(2), \fBgetgrouplist\fP(3), \fBgroup\fP(5)
+.SH この文書について
+この man ページは Linux \fIman\-pages\fP プロジェクトのリリース 3.76 の一部
+である。プロジェクトの説明とバグ報告に関する情報は
+http://www.kernel.org/doc/man\-pages/ に書かれている。
--- /dev/null
+.\" t
+.\" Copyright (C) 2014 Michael Kerrisk <mtk.manpages@gmail.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 ISFDTYPE 3 2014\-03\-13 Linux "Linux Programmer's Manual"
+.SH 名前
+isfdtype \- ファイルディスクリプタのファイル種別を検査する
+.SH 書式
+.nf
+\fB#include <sys/stat.h>\fP
+\fB#include <sys/socket.h>\fP
+
+\fBint isfdtype(int \fP\fIfd\fP\fB, int \fP\fIfdtype\fP\fB);\fP
+.fi
+.sp
+.in -4n
+glibc 向けの機能検査マクロの要件 (\fBfeature_test_macros\fP(7) 参照):
+.in
+.sp
+\fBisfdtype\fP():
+.ad l
+.RS 4
+.PD 0
+.TP 4
+glibc 2.20 以降:
+_DEFAULT_SOURCE
+.TP 4
+glibc 2.20 より前:
+_BSD_SOURCE || _SVID_SOURCE
+.PD
+.RE
+.ad b
+.SH 説明
+\fBisfdtype\fP() 関数はファイルディスクリプタ \fIfd\fP がタイプが \fIfdtype\fP のファイルを参照しているかを検査する。
+\fIfdtype\fP 引き数には、\fI<sys/stat.h>\fP で定義されている \fBS_IF*\fP 定数のひとつ (\fBS_IFREG\fP
+など) を指定する。 \fBS_IF*\fP 定数の説明は \fBstat\fP(2) にある。
+.SH 返り値
+\fBisfdtype\fP() 関数は、ファイルディスクリプタ \fIfd\fP がタイプ \fIfdtype\fP であった場合に 1 を返し、そうでない場合に 0
+を返す。 エラーの場合、 \-1 を返し、\fIerrno\fP に原因を示す値を設定する。
+.SH エラー
+\fBisfdtype\fP() 関数は \fBfstat\fP(3) と同じエラーで失敗する。
+.SH 準拠
+\fBisfdtype\fP() 関数はどの標準でも規定されていないが、 POSIX.1g 標準のドラフトに登場したことはある。 OpenBSD と
+Tru64 UNIX に存在し、おそらく他のシステムにも存在する (OpenBSD と Tru64 UNIX のどちらの場合でも必要なヘッダーファイルは
+\fI<sys/stat.h>\fP だけであり、POSIX.1g ドラフトに書かれていたのと同じである)。
+.SH 注意
+移植性が求められるアプリケーションでは \fBfstat\fP(3) を使用すべきである。
+.SH 関連項目
+\fBfstat\fP(3)
+.SH この文書について
+この man ページは Linux \fIman\-pages\fP プロジェクトのリリース 3.76 の一部
+である。プロジェクトの説明とバグ報告に関する情報は
+http://www.kernel.org/doc/man\-pages/ に書かれている。
.fi
.sp
.\" in libc 5.0.9, not in 4.7.6
-The type \fIloff_t\fP is a 64\-bit signed type. The library routine \fBllseek\fP()
-is available in the glibc and works without special defines. However, the
-glibc headers do not provide a prototype. Users should add the above
-prototype, or something equivalent, to their own source. When users
-complained about data loss caused by a miscompilation of \fBe2fsck\fP(8), glibc
-2.1.3 added the link\-time warning
+型 \fIloff_t\fP は 64 ビット符号付き型である。 ライブラリルーチン \fBllseek\fP() は glibc で利用可能であり、
+特別な定義なしに動作する。 しかしながら、 glibc のヘッダーはプロトタイプを供していない。 ユーザは上記のプロトタイプまたはそれと同等のものを、
+自身のソースに追加しなければならない。 このデータがないことによって \fBe2fsck\fP(8) のコンパイルが失敗するという苦情がユーザから出たので、
+glibc 2.1.3 では以下のようなリンク時の警告が追加された。
.sp
.in +4n
"the \`llseek\' function may be dangerous; use \`lseek64\' instead."
Linux では、 \fBmq_getattr\fP() と \fBmq_setattr\fP() はライブラリ関数であり、
\fBmq_getsetattr\fP(2) システムコールを用いて実装されている。
.SH 例
-The program below can be used to show the default \fImq_maxmsg\fP and
-\fImq_msgsize\fP values that are assigned to a message queue that is created
-with a call to \fBmq_open\fP(3) in which the \fIattr\fP argument is NULL. Here
-is an example run of the program:
+下記のプログラムを使うと、 \fIattr\fP 引き数に NULL を指定して \fBmq_open\fP(3)
+を呼び出した際に作成されるメッセージキューに割り当てられるデフォルトの \fImq_maxmsg\fP と \fImq_msgsize\fP の値を表示できる。
+このプログラムの実行例を以下に示す。
.in +4n
.nf
.fi
.in
-Since Linux 3.5, the following \fI/proc\fP files (described in
-\fBmq_overview\fP(7)) can be used to control the defaults:
+Linux 3.5 以降では、 (\fBmq_overview\fP(7) に説明がある) 以下の \fI/proc\fP
+ファイルを使ってデフォルト値を制御できる。
.in +4n
.nf
.TP
\fBO_CLOEXEC\fP (Linux 2.6.26 以降)
.\" commit 269f21344b23e552c21c9e2d7ca258479dcd7a0a
-Set the close\-on\-exec flag for the message queue descriptor. See \fBopen\fP(2)
-for a discussion of why this flag is useful.
+メッセージキュー記述子に close\-on\-exec フラグをセットする。 なぜこのフラグが有用かについての議論は \fBopen\fP(2) を参照。
.TP
\fBO_CREAT\fP
.\" In reality the filesystem IDs are used on Linux.
.br
\fBint \fP\fIsys_nerr\fP\fB;\fP
.br
-\fBint \fP\fIerrno\fP\fB; /* Not really declared this way; see errno(3). */\fP
+\fBint \fP\fIerrno\fP\fB; /* 実際にこのように宣言されているわけではない。 errno(3) 参照 */\fP
.sp
.in -4n
glibc 向けの機能検査マクロの要件 (\fBfeature_test_macros\fP(7) 参照):
--- /dev/null
+.\"Copyright (c) 2010 Novell Inc., written by Robert Schweikert
+.\"
+.\" %%%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 verbat`im 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 PTHREAD_RWLOCKATTR_SETKIND_NP 3 2014\-10\-15 "Linux Programmer's Manual"
+.SH 名前
+pthread_rwlockattr_setkind_np, pthread_rwlockattr_getkind_np \-
+スレッドの読み書きロック属性オブジェクトの読み書きロック種別の設定、取得を行う
+.SH 書式
+.nf
+\fB#include <pthread.h>\fP
+
+\fBint pthread_rwlockattr_setkind_np(pthread_rwlockattr_t *\fP\fIattr\fP\fB,\fP
+\fB int \fP\fIpref\fP\fB);\fP
+\fBint pthread_rwlockattr_getkind_np(const pthread_rwlockattr_t *\fP\fIattr\fP\fB,\fP
+\fB int *\fP\fIpref\fP\fB);\fP
+.sp
+\fI\-pthread\fP でコンパイルしてリンクする。
+.sp
+.fi
+.in -4n
+glibc 向けの機能検査マクロの要件 (\fBfeature_test_macros\fP(7) 参照):
+.in
+.sp
+\fBpthread_rwlockattr_setkind_np\fP(), \fBpthread_rwlockattr_getkind_np\fP():
+.br
+.RS 4
+.ad l
+_XOPEN_SOURCE\ >=\ 500 || _POSIX_C_SOURCE >= 200809L
+.RE
+.ad
+.SH 説明
+\fBpthread_rwlockattr_setkind_np\fP() 関数は、 \fIattr\fP が参照する読み書きロック属性オブジェクトの「ロック種別
+(lock kind)」を \fIpref\fP で指定された値に設定する。 引き数 \fIpref\fP には以下のいずれか一つを設定できる。
+.TP
+\fBPTHREAD_RWLOCK_PREFER_READER_NP\fP
+これがデフォルトである。 スレッドは複数の読み出しロックを保持できる。 つまり、読み出しロックは再帰的である。 Single Unix
+Specification では、 読み出し側がロックをかけようとした際に、書き込みロックはないが書き込み側が待っていた場合の、動作は規定されていない。
+\fBPTHREAD_RWLOCK_PREFER_READER_NP\fP に設定し、読み出し側に優先度を与えるということは、
+たとえ書き込み側が待っていたとしても、読み出し側が要求したロックを受け取ることを意味する。 読み出し側がいる限り、書き込み側は待つことになる。
+.TP
+\fBPTHREAD_RWLOCK_PREFER_WRITER_NP\fP
+これは \fBPTHREAD_RWLOCK_PREFER_READER_NP\fP の書き込みロック版である。 ただし「バグ」を参照のこと。
+.TP
+\fBPTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP\fP
+ロック種別をこの値に設定すると、 読み出しロックが再帰的に行われない限りは、 書き込み側の待ちを避けることができる。
+.PP
+\fBpthread_rwlockattr_getkind_np\fP() 関数は、 \fIattr\fP
+が参照する読み書きロック属性オブジェクトのロック種別属性の値をポインター \fIpref\fP に入れて返す。
+.SH 返り値
+成功すると、これらの関数は 0 を返す。 有効なポインター引き数が渡された場合、 \fBpthread_rwlockattr_getkind_np\fP()
+は常に成功する。 エラーの場合、 \fBpthread_rwlockattr_setkind_np\fP() は 0 以外のエラー番号を返す。
+.SH エラー
+.TP
+\fBEINVAL\fP
+\fIpref\fP にサポート外の値が指定された。
+.SH バグ
+.\" http://sourceware.org/bugzilla/show_bug.cgi?id=7057
+読み書きロック種別の値を \fBPTHREAD_RWLOCK_PREFER_WRITER_NP\fP に設定することは、 値を
+\fBPTHREAD_RWLOCK_PREFER_READER_NP\fP に設定するのと同じ動作となる。
+読み出しスレッドがロックを保持する限り、書き込みロックを保持しているスレッドは停止することになる。 ロック種別を
+\fBPTHREAD_RWLOCK_PREFER_WRITER_NONRECURSIVE_NP\fP に設定すると、
+書き込み側が動作できるようになるが、変数名から分かるように、 書き込み側はロックを再帰的に行うことはできない。
+.SH バージョン
+関数 \fBpthread_rwlockattr_getkind_np\fP() と \fBpthread_rwlockattr_setkind_np\fP() は
+glibc 2.1 で初めて登場した。
+.SH 準拠
+これらの関数は非標準の GNU による拡張である。 そのため、名前に "_np" (non\-portable; 移植性がない)
+という接尾辞が付いている。
+.SH 関連項目
+\fBpthreads\fP(7)
+.SH この文書について
+この man ページは Linux \fIman\-pages\fP プロジェクトのリリース 3.76 の一部
+である。プロジェクトの説明とバグ報告に関する情報は
+http://www.kernel.org/doc/man\-pages/ に書かれている。
指定したシグナル番号が不正である。
.SH 属性
.SS "マルチスレッディング (pthreads(7) 参照)"
-The \fBsiginterrupt\fP() function uses a global variable that is not
-protected, so it is not thread\-safe.
+\fBsiginterrupt\fP() 関数は保護されていないグローバル変数を使用しているので、スレッドセーフではない。
.SH 準拠
4.3BSD, POSIX.1\-2001. POSIX.1\-2008 は、 \fBsiginterrupt\fP() を廃止予定としている。 代わりに、
\fBsigaction\fP(2) に \fBSA_RESTART\fP フラグを指定して使うことを推奨している。
.LP
\fBsigmask\fP() マクロはスレッドセーフである。
.SH バージョン
-Starting with version 2.21, the GNU C library no longer exports the
-\fBsigvec\fP() function as part of the ABI. (To ensure backward
-compatibility, the glibc symbol versioning scheme continues to export the
-interface to binaries linked against older versions of the library.)
+バージョン 2.21 以降では、 GNU C ライブラリはもはや \fBsigvec\fP() 関数を ABI の一部として公開しなくなった。
+(後方互換性を保証するために、glibc のシンボルのバージョン付け機構により、
+古いバージョンのライブラリとリンクされたバイナリに対してはこのインタフェースが引き続き公開されている。)
.SH 準拠
これらの関数のうち \fBsiggetmask\fP() 以外の全ては 4.3BSD にあった。 \fBsiggetmask\fP() の出自ははっきりしない。
これらの関数は廃止予定であり、新しいプログラムでは使用しないこと。
TZ=":Pacific/Auckland"
.fi
.SH ファイル
-Under glibc, the system timezone directory is determined using the \fBTZDIR\fP
-the environment variable. If \fBTZDIR\fP is not set, the default depends on
-the system setup, but is normally \fI/usr/share/zoneinfo\fP.
+glibc では、システムのタイムゾーンディレクトリは \fBTZDIR\fP 環境変数を使って決定される。 \fBTZDIR\fP
+がセットされていない場合、デフォルト値はシステム設定依存となるが、通常は \fI/usr/share/zoneinfo\fP である。
.LP
このタイムゾーンディレクトリには以下のファイルが含まれる。
.PP
文字集合定義のセクションは文字列 \fIEND CHARMAP\fP で終了する。
.PP
-The character set definition section may optionally be followed by a section
-to define widths of characters.
+文字集合定義のセクションの後ろに、文字幅を定義するセクションを続けることができる。
.PP
-The \fBWIDTH_DEFAULT\fP keyword can be used to define the default width for all
-characters not explicitly listed. The default character width is 1.
+\fBWIDTH_DEFAULT\fP キーワードを使って、リストに明示的に載っていない全文字で使用されるデフォルトの文字幅を定義できる。
+デフォルトの文字幅は 1 である。
.PP
個別の文字の文字幅定義のセクションは、 第一カラムにキーワード \fBWIDTH\fP を置いて開始する。
.SH ファイル
.TP
\fI/usr/share/i18n/charmaps\fP
-Usual default character map path.
+デフォルトのキャラクターマップの通常のパス。
.SH 準拠
POSIX.2.
.SH 例
-The Euro sign is defined as follows in the \fIUTF\-8\fP charmap:
+ユーロ記号は \fIUTF\-8\fP キャラクターマップでは以下のように定義される。
.PP
.nf
<U20AC> /xe2/x82/xac
番目の検索要求を送信する前にソケットをクローズし 新しいソケットをオープンするようになる。
.TP
\fBno\-tld\-query\fP (glibc 2.14 以降)
-sets RES_NOTLDQUERY in \fI_res.options\fP. This option causes \fBres_nsearch()\fP
-to not attempt to resolve an unqualified name as if it were a top level
-domain (TLD). This option can cause problems if the site has \*(lqlocalhost\*(rq
-as a TLD rather than having localhost on one or more elements of the search
-list. This option has no effect if neither RES_DEFNAMES or RES_DNSRCH is
-set.
+RES_NOTLDQUERY を \fI_res.options\fP にセットする。 このオプションを設定すると、 \fBres_nsearch\fP()
+が完全なドメイン名ではない名前のトップレベルドメイン (TLD) としての検索を行わなくなる。 これにより、localhost
+に検索リストの要素をつけるのではなく、\*(lqlocalhost\*(rq を TLD として設定しているようなサイトでは問題が起こる可能性がある。
+RES_DEFNAMES も RES_DNSRCH もセットされていない場合には、このオプションは効果はない。
.RE
.LP
\fIdomain\fP と \fIsearch\fP キーワードは、互いに排他的である。 これらのキーワードが 2 つ以上記述されている場合、
\fBCAP_AUDIT_READ\fP (Linux 3.16 以降)
.\" commit a29b694aa1739f9d76538e34ae25524f9c549d59
.\" commit 3a101b8de0d39403b2c7e5c23fd0b005668acf48
-Allow reading the audit log via a multicast netlink socket.
+マルチキャスト netlink ソケット経由で監査ログの読み出しができる。
.TP
\fBCAP_AUDIT_WRITE\fP (Linux 2.6.11 以降)
カーネル監査のログにレコードを書き込む。
.IP *
特権が必要な \fIperf\fP イベントの情報にアクセスする。
.IP *
-call \fBsetns\fP(2) (requires \fBCAP_SYS_ADMIN\fP in the \fItarget\fP namespace);
+\fBsetns\fP(2) を呼び出す (\fItarget\fP 名前空間での \fBCAP_SYS_ADMIN\fP が必要)。
.IP *
\fBfanotify_init\fP(2) を呼び出す。
.IP *
.IP *
\fBget_robust_list\fP(2) を任意のプロセスに対して行う。
.IP *
-transfer data to or from the memory of arbitrary processes using
-\fBprocess_vm_readv\fP(2) and \fBprocess_vm_writev\fP(2).
+\fBprocess_vm_readv\fP(2) と \fBprocess_vm_writev\fP(2)
+を使って任意のプロセスのメモリとの間でデータの送受信を行う。
.IP *
\fBkcmp\fP(2) を使ってプロセス内部を調査する。
.RE
SECBIT_NOROOT_LOCKED);
.fi
.in
-.SS "Interaction with user namespaces"
-For a discussion of the interaction of capabilities and user namespaces, see
-\fBuser_namespaces\fP(7).
+.SS ユーザー名前空間との相互作用
+ケーパリビティとユーザー名前空間の相互の影響に関する議論は \fBuser_namespaces\fP(7) を参照。
.SH 準拠
.PP
ケーパビリティに関する標準はないが、 Linux のケーパビリティは廃案になった POSIX.1e 草案に基づいて実装されている。
によるイベントを受信した後で、関連するファイルディスクリプタを無効にさせる。 \fBEPOLLONESHOT\fP フラグが指定された場合、
\fBepoll_ctl\fP(2) に \fBEPOLL_CTL_MOD\fP を指定してファイルディスクリプタを再度使用できるようにするのは、
呼び出し側の責任である。
-.SS "Interaction with autosleep"
-If the system is in \fBautosleep\fP mode via \fI/sys/power/autosleep\fP and an
-event happens which wakes the device from sleep, the device driver will only
-keep the device awake until that event is queued. To keep the device awake
-until the event has been processed, it is necessary to use the \fBepoll\fP(7)
-\fBEPOLLWAKEUP\fP flag.
+.SS "autosleep との関係"
+システムが \fI/sys/power/autosleep\fP 経由で \fBautosleep\fP モードになっていて、
+デバイスをスリープ状態から起こすイベントが発生した場合、
+そのイベントがキューに入るまでは、デバイスドライバーはデバイスを起こしたままにしておくだけである。
+イベントが処理されるまでデバイスを起こしたままにしておくには、 \fBepoll\fP(7) \fBEPOLLWAKEUP\fP フラグを使う必要がある。
-When the \fBEPOLLWAKEUP\fP flag is set in the \fBevents\fP field for a \fIstruct
-epoll_event\fP, the system will be kept awake from the moment the event is
-queued, through the \fBepoll_wait\fP(2) call which returns the event until the
-subsequent \fBepoll_wait\fP(2) call. If the event should keep the system
-awake beyond that time, then a separate \fIwake_lock\fP should be taken before
-the second \fBepoll_wait\fP(2) call.
+\fBEPOLLWAKEUP\fP フラグが \fIstruct epoll_event\fP の \fBevents\fP フィールドでセットされた場合、
+イベントがキューに入った瞬間から、\fBepoll_wait\fP(2) がそのイベントを返し次の \fBepoll_wait\fP(2)
+の呼び出しが行われるまでの間、システムは起きたままの状態になる。
+イベントが上記の時間の範囲を超えてシステムを起きたままの状態にしておく必要がある場合は、 2 番目の \fBepoll_wait\fP(2)
+の呼び出しの前に別の \fIwake_lock\fP を取る必要がある。
.SS "/proc インタフェース"
.\" Following was added in 2.6.28, but them removed in 2.6.29
.\" .TP
ファイルやディレクトリがオープンされた。
.RE
.PP
-When monitoring a directory:
+ディレクトリを監視する場合:
.IP * 3
-the events marked above with an asterisk (*) can occur both for the
-directory itself and for objects inside the directory; and
+上記でアスタリスク (*) が付いたイベントは、 ディレクトリ自身とディレクトリ内のオブジェクトのどちらに対しても発生する。
.IP *
-the events marked with a plus sign (+) occur only for objects inside the
-directory (not for the directory itself).
+上記でプラス記号 (+) が付いたイベントは、 ディレクトリ内のオブジェクトに対してのみ発生する (ディレクトリ自身に対しては発生しない)。
.PP
-When events are generated for objects inside a watched directory, the
-\fIname\fP field in the returned \fIinotify_event\fP structure identifies the name
-of the file within the directory.
+監視対象のディレクトリ内のオブジェクトに対してイベントが発生した場合、 \fIinotify_event\fP 構造体で返される \fIname\fP
+フィールドは、ディレクトリ内のファイル名を表す。
.PP
\fBIN_ALL_EVENTS\fP マクロは上記のイベント全てのマスクとして定義される。 このマクロは \fBinotify_add_watch\fP(2)
を呼び出すときの \fImask\fP 引き数として使える。
を指定するとこのデフォルトの動作を変更でき、監視対象のディレクトリから子ファイルが削除された後に子ファイルに関するイベントが生成されなくなる。
.TP
\fBIN_MASK_ADD\fP
-If a watch instance already exists for the filesystem object corresponding
-to \fIpathname\fP, add (OR) the events in \fImask\fP to the watch mask (instead of
-replacing the mask).
+監視インスタンスが \fIpathname\fP に対応するファイルシステムオブジェクトに対してすでに存在する場合に、 (マスクを置き換えるのではなく)
+監視マスクに \fImask\fP で指定されたイベントを追加 (OR) する。
.TP
\fBIN_ONESHOT\fP
-Monitor the filesystem object corresponding to \fIpathname\fP for one event,
-then remove from watch list.
+\fIpathname\fP に対応するファイルシステムオブジェクトを 1 イベントについてだけ監視し、 イベントが発生したら監視対象リストから削除する。
.TP
\fBIN_ONLYDIR\fP (Linux 2.6.15 以降)
-Only watch \fIpathname\fP if it is a directory. Using this flag provides an
-application with a race\-free way of ensuring that the monitored object is a
-directory.
+\fIpathname\fP がディレクトリの場合のみ監視する。
+このフラグを使うことで、アプリケーションは、競合状態を考慮せずに、監視するオブジェクトがディレクトリであることを保証することができるようになる。
.RE
.PP
以下のビットが \fBread\fP(2) で返される \fImask\fP フィールドに設定される:
上述の通り、 \fBrename\fP(2) により生成される \fBIN_MOVED_FROM\fP と \fBIN_MOVED_TO\fP イベントの組は、共有される
cookie 値によって対応を取ることができる。 しかし、対応を取る場合にはいくつか難しい点がある。
-These two events are usually consecutive in the event stream available when
-reading from the inotify file descriptor. However, this is not guaranteed.
-If multiple processes are triggering events for monitored objects, then (on
-rare occasions) an arbitrary number of other events may appear between the
-\fBIN_MOVED_FROM\fP and \fBIN_MOVED_TO\fP events. Furthermore, it is not
-guaranteed that the event pair is atomically inserted into the queue: there
-may be a brief interval where the \fBIN_MOVED_FROM\fP has appeared, but the
-\fBIN_MOVED_TO\fP has not.
+これらの 2 つのイベントは、 inotify ファイルディスクリプタから読み出しを行った場合に、通常はイベントストリーム内で連続している。
+しかしながら、連続していることは保証されていない。 複数のプロセスが監視対象オブジェクトでイベントを発生させた場合、 (めったに起こらないことだが)
+イベント \fBIN_MOVED_FROM\fP と \fBIN_MOVED_TO\fP の間に任意の数の他のイベントがはさまる可能性がある。
+さらに、対となるイベントがアトミックにキューに挿入されることも保証されていない。 \fBIN_MOVED_FROM\fP が現れたが
+\fBIN_MOVED_TO\fP は現れていないという短い期間がありえるということだ。
したがって、 \fBrename\fP(2) により生成された \fBIN_MOVED_FROM\fP と \fBIN_MOVED_TO\fP
のイベントの組の対応を取るのは本質的に難しいことである (監視対象のディレクトリの外へオブジェクトの rename が行われた場合には
結果的に、監視対象ディスクリプタが破棄され再作成された場合、これらの監視対象ディスクリプタは、処理待ちイベントの監視対象ディスクリプタと一貫性のないものになってしまう
(inotify ファイルディスクリプタの再作成とキャッシュの再構成はこの状況に対処するのに有用な方法なのだが)。
-Applications should also allow for the possibility that the \fBIN_MOVED_FROM\fP
-event was the last event that could fit in the buffer returned by the
-current call to \fBread\fP(2), and the accompanying \fBIN_MOVED_TO\fP event might
-be fetched only on the next \fBread\fP(2), which should be done with a (small)
-timeout to allow for the fact that insertion of the
-\fBIN_MOVED_FROM\fP\-\fBIN_MOVED_TO\fP event pair is not atomic, and also the
-possibility that there may not be any \fBIN_MOVED_TO\fP event.
+また、アプリケーションは、 \fBIN_MOVED_FROM\fP イベントが今行った \fBread\fP(2)
+の呼び出しで返されたバッファのちょうど一番最後のイベントで、 \fBIN_MOVED_TO\fP イベントは次の \fBread\fP(2)
+を行わないと取得できない可能性も考慮に入れる必要がある。 2 つ目の \fBread\fP(2) は (短い) タイムアウトで行うべきである。 これは、
+\fBIN_MOVED_FROM\fP\-\fBIN_MOVED_TO\fP のイベントペアのキューへの挿入はアトミックではなく、 また \fBIN_MOVED_TO\fP
+イベントが全く発生しない可能性もあるという事実を考慮に入れておく必要があるからである。
.SH バグ
-As of kernel 3.17, calling \fBfallocate\fP(2) does not create any inotify
-events.
+カーネル 3.17 時点では、 \fBfallocate\fP(2) の呼び出しでは inotify イベントが生成されない。
.\" FIXME . kernel commit 611da04f7a31b2208e838be55a42c7a1310ae321
.\" implies that unmount events were buggy 2.6.11 to 2.6.36
をチェックするようになっていた。
.\" FIXME . https://bugzilla.kernel.org/show_bug.cgi?id=77111
-When a watch descriptor is removed by calling \fBinotify_rm_watch\fP(2) (or
-because a watch file is deleted or the filesystem that contains it is
-unmounted), any pending unread events for that watch descriptor remain
-available to read. As watch descriptors are subsequently allocated with
-\fBinotify_add_watch\fP(2), the kernel cycles through the range of possible
-watch descriptors (0 to \fBINT_MAX\fP) incrementally. When allocating a free
-watch descriptor, no check is made to see whether that watch descriptor
-number has any pending unread events in the inotify queue. Thus, it can
-happen that a watch descriptor is reallocated even when pending unread
-events exist for a previous incarnation of that watch descriptor number,
-with the result that the application might then read those events and
-interpret them as belonging to the file associated with the newly recycled
-watch descriptor. In practice, the likelihood of hitting this bug may be
-extremely low, since it requires that an application cycle through
-\fBINT_MAX\fP watch descriptors, release a watch descriptor while leaving
-unread events for that watch descriptor in the queue, and then recycle that
-watch descriptor. For this reason, and because there have been no reports
-of the bug occurring in real\-world applications, as of Linux 3.15, no kernel
-changes have yet been made to eliminate this possible bug.
+\fBinotify_rm_watch\fP(2) の呼び出しにより監視対象ディスクリプタが削除された場合
+(なお、監視対象ファイルの削除や監視対象ファイルが含まれるファイルシステムのアンマウントによっても監視対象ディスクリプタは削除される)、
+この監視対象ディスクリプタ関連の処理待ちの未読み出しイベントは、 読み出し可能なままとなる。 監視対象ディスクリプタは
+\fBinotify_add_watch\fP(2) によって後で割り当てられるため、 カーネルは利用可能な監視対象ディスクリプタの範囲 (0 から
+\fBINT_MAX\fP) から昇順にサイクリックに割り当てを行う。未使用の監視対象ディスクリプタを割り当てる際、 その監視対象ディスクリプタ番号に
+inotify キューで処理待ちの未読み出しイベントがあるかの確認は行われない。 したがって、監視対象ディスクリプタが再割り当てされた際に、
+その監視対象ディスクリプタの一つ前の使用時に発生した処理待ちの未読み出しイベントが存在するということが起こりうる。
+その結果、アプリケーションはこれらのイベントを読み出す可能性があり、
+これらのイベントが新しく再利用された監視対象ディスクリプタに関連付けられたファイルに属するものかを解釈する必要が出て来る。
+実際のところ、このバグを踏む可能性は極めて低い。 それは、このバグを踏むためには、アプリケーションが \fBINT_MAX\fP
+個の監視対象ディスクリプタが一周させて、 キューに未読み出しイベントが残っている監視対象ディスクリプタを解放し、
+その監視対象ディスクリプタを再利用する必要があるからである。 この理由と、実世界のアプリケーションで発生したというバグ報告がないことから、 Linux
+3.15 時点では、この計算上は起こりうるバグを取り除くためのカーネルの変更は行われていない。
.SH 例
以下のプログラムは inotify API の使用例を示したものである。 コマンドライン引き数で渡されたディレクトリに印を付け、 タイプが
\fBIN_OPEN\fP, \fBIN_CLOSE_NOWRITE\fP \fBIN_CLOSE_WRITE\fP のイベントを待つ。
.TP
\fIip_local_port_range\fP (Linux 2.2 以降)
.\" Precisely: since 2.1.68
-This file contains two integers that define the default local port range
-allocated to sockets that are not explicitly bound to a port number\(emthat
-is, the range used for \fIephemeral ports\fP. An ephemeral port is allocated
-to a socket in the following circumstances:
+このファイルには、 ポート番号に明示的にバインドされないソケットに割り当てられるデフォルトのローカルポートの範囲 \(em つまり「一時ポート
+(\fIephemeral ports\fP)」に使用される範囲 \(em を定める 2 つの整数が入っている。
+一時ポートは以下の場合にソケットに割り当てられる。
.RS
.IP * 3
-the port number in a socket address is specified as 0 when calling
-\fBbind\fP(2);
+\fBbind\fP(2) の呼び出し時にソケットアドレスのポート番号に 0 が指定されている。
.IP *
-\fBlisten\fP(2) is called on a stream socket that was not previously bound;
+バインドされていないストリームソケットに対して \fBlisten\fP(2) が呼び出された。
.IP *
バインドされていないソケットに対して \fBconnect\fP(2) が呼ばれた。
.IP *
バインドされていないデータグラムソケットに対して \fBsendto\fP(2) が呼ばれた。
.RE
.IP
-一時ポート (ephemeral port) に割り当てられるポート番号の範囲は、 \fIip_local_port_range\fP
-の最初の数字から始まり、 2 番目の数字で終わる。 一時ポートの範囲を使い切った場合、 関連するシステムコールはエラーを返す (バグの節を参照)。
+一時ポートに割り当てられるポート番号の範囲は、 \fIip_local_port_range\fP の最初の数字から始まり、 2 番目の数字で終わる。
+一時ポートの範囲を使い切った場合、 関連するシステムコールはエラーを返す (バグの節を参照)。
.IP
.\"
\fIip_local_port_range\fP で指定するポート番号の範囲は、 マスカレードで用いられているポートと重なってはならない
.SH バグ
エラーの値がまったく首尾一貫していない。
.PP
-The error used to diagnose exhaustion of the ephemeral port range differs
-across the various system calls (\fBconnect\fP(2), \fBbind\fP(2), \fBlisten\fP(2),
-\fBsendto\fP(2)) that can assign ephemeral ports.
+一時ポートの範囲の枯渇を示すのに使われるエラーは、 一時ポートの割り当てを行えるシステムコール (\fBconnect\fP(2), \fBbind\fP(2),
+\fBlisten\fP(2), \fBsendto\fP(2)) により異なる。
.PP
.\" .PP
.\" Some versions of glibc forget to declare
新規のメッセージキューのデフォルト属性を設定したりすることができる。
.TP
\fI/proc/sys/fs/mqueue/msg_default\fP (Linux 3.5 以降)
-This file defines the value used for a new queue's \fImq_maxmsg\fP setting when
-the queue is created with a call to \fBmq_open\fP(3) where \fIattr\fP is
-specified as NULL. The default value for this file is 10. The minimum and
-maximum are as for \fI/proc/sys/fs/mqueue/msg_max\fP. A new queue's default
-\fImq_maxmsg\fP value will be the smaller of \fImsg_default\fP and \fImsg_max\fP. Up
-until Linux 2.6.28, the default \fImq_maxmsg\fP was 10; from Linux 2.6.28 to
-Linux 3.4, the default was the value defined for the \fImsg_max\fP limit.
+このファイルは、\fIattr\fP に NULL を指定して \fBmq_open\fP(3) を呼び出してキューが作成された際に、 その新規キューの
+\fImq_maxmsg\fP 設定に使用される値を定めている。 このファイルのデフォルト値は 10 である。 最小値と最大値は
+\fI/proc/sys/fs/mqueue/msg_max\fP と同様である。 新規キューのデフォルトの \fImq_maxmsg\fP 値は
+\fImsg_default\fP と \fImsg_max\fP の小さい方となる。 Linux 2.6.28 より前は、デフォルトの \fImq_maxmsg\fP
+は 10 であった。 Linux 2.6.28 から Linux 3.4 までは、 デフォルト値は \fImsg_max\fP 上限で規定される値であった。
.TP
\fI/proc/sys/fs/mqueue/msg_max\fP
このファイルを使って、一つのキューに入れられるメッセージの最大数の 上限値を参照したり変更したりできる。この値は、 \fBmq_open\fP(3) に渡す
.RE
.TP
\fI/proc/sys/fs/mqueue/msgsize_default\fP (Linux 3.5 以降)
-This file defines the value used for a new queue's \fImq_msgsize\fP setting
-when the queue is created with a call to \fBmq_open\fP(3) where \fIattr\fP is
-specified as NULL. The default value for this file is 8192 (bytes). The
-minimum and maximum are as for \fI/proc/sys/fs/mqueue/msgsize_max\fP. If
-\fImsgsize_default\fP exceeds \fImsgsize_max\fP, a new queue's default
-\fImq_msgsize\fP value is capped to the \fImsgsize_max\fP limit. Up until Linux
-2.6.28, the default \fImq_msgsize\fP was 8192; from Linux 2.6.28 to Linux 3.4,
-the default was the value defined for the \fImsgsize_max\fP limit.
+このファイルは、\fIattr\fP に NULL を指定して \fBmq_open\fP(3) を呼び出してキューが作成された際に、 その新規キューの
+\fImq_msgsize\fP 設定に使用される値を定めている。 このファイルのデフォルト値は 8192 バイトである。 最小値と最大値は
+\fI/proc/sys/fs/mqueue/msgsize_max\fP と同様である。
+\fImsgsize_default\fP が \fImsgsize_max\fP より大きい場合は、 新規キューのデフォルトの \fImq_msgsize\fP 値は
+\fImsgsize_max\fP 上限となる。 Linux 2.6.28 より前は、デフォルトの \fImq_msgsize\fP は 8192 であった。
+Linux 2.6.28 から Linux 3.4 までは、 デフォルト値は \fImsgsize_max\fP 上限で規定される値であった。
.TP
\fI/proc/sys/fs/mqueue/msgsize_max\fP
このファイルを使って、メッセージの最大サイズの上限値を参照したり変更したりできる。 この値は、 \fBmq_open\fP(3) に渡す
Linux 3.5 以降では、上限は 16,777,216 (\fBHARD_MSGSIZEMAX\fP) である。
.RE
.IP
-The \fImsgsize_max\fP limit is ignored for privileged process
-(\fBCAP_SYS_RESOURCE\fP), but, since Linux 3.5, the \fBHARD_MSGSIZEMAX\fP ceiling
-is enforced for privileged processes.
+\fImsgsize_max\fP 上限は特権プロセス (\fBCAP_SYS_RESOURCE\fP) では無視されるが、 Linux 3.5
+以降では特権プロセスにも \fBHARD_MSGSIZEMAX\fP という上限が適用される。
.TP
\fI/proc/sys/fs/mqueue/queues_max\fP
このファイルを使って、作成可能なメッセージキュー数のシステム全体での制限を参照したり変更したりできる。 \fIqueues_max\fP のデフォルト値は
Linux では、メッセージキュー記述子は実際はファイル記述子 (file descriptor) であり、 \fBselect\fP(2),
\fBpoll\fP(2), \fBepoll\fP(7) を使って監視することができる。 この機能の移植性はない。
.SS "IPC 名前空間"
-For a discussion of the interaction of System V IPC objects and IPC
-namespaces, see \fBnamespaces\fP(7).
+System V IPC オブジェクトと IPC 名前空間の相互の影響に関する議論は \fBnamespaces\fP(7) を参照。
.SH 準拠
POSIX.1\-2001.
.SH 注意
.SH 例
各種のメッセージキュー関数を使用した例が \fBmq_notify\fP(3) に記載されている。
.SH バグ
-In Linux versions 3.5 to 3.14, the kernel imposed a ceiling of 1024
-(\fBHARD_QUEUESMAX\fP) on the value to which the \fIqueues_max\fP limit could be
-raised, and the ceiling was enforced even for privileged processes. This
-ceiling value was removed in Linux 3.14, and patches to stable kernels 3.5.x
-to 3.13.x also removed the ceiling.
+バージョン 3.5 以降 3.14 未満の Linux では、 \fIqueues_max\fP 上限を増やすことができる最大値として 1024
+(\fBHARD_QUEUESMAX\fP) という最大上限値がカーネルにより適用されていた。 この最大上限値は特権プロセスにも適用されていた。
+この最大上限値は Linux 3.14 で削除され、 パッチで安定版カーネル 3.5.x から 3.13.x からもこの最大上限値は削除された。
.SH 関連項目
\fBgetrlimit\fP(2), \fBmq_getsetattr\fP(2), \fBpoll\fP(2), \fBselect\fP(2),
\fBmq_close\fP(3), \fBmq_getattr\fP(3), \fBmq_notify\fP(3), \fBmq_open\fP(3),
--- /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 NAMESPACES 7 2014\-09\-21 Linux "Linux Programmer's Manual"
+.SH 名前
+namespaces \- Linux 名前空間の概要
+.SH 説明
+名前空間は、 グローバルシステムリソースを抽象化層で覆うことで、 名前空間内のプロセスに対して、
+自分たちが専用の分離されたグローバルリソースを持っているかのように見せる仕組みである。 グローバルリソースへの変更は、
+名前空間のメンバーである他のプロセスには見えるが、 それ以外のプロセスには見えない。 名前空間の一つの利用方法はコンテナーの実装である。
+
+Linux では以下の名前空間が提供される。
+.TS
+lB lB lB
+l lB l.
+名前空間 定数 分離対象
+IPC CLONE_NEWIPC System V IPC, POSIX メッセージキュー
+Network CLONE_NEWNET ネットワークデバイス、スタック、ポートなど
+Mount CLONE_NEWNS マウントポイント
+PID CLONE_NEWPID プロセス ID
+User CLONE_NEWUSER ユーザー ID とグループ ID
+UTS CLONE_NEWUTS ホスト名と NIS ドメイン名
+.TE
+
+.\"
+.\" ==================== The namespaces API ====================
+.\"
+このページでは、各種の名前空間と関連する \fI/proc\fP ファイルの説明と、名前空間とともに動作する API の概要を紹介する。
+.SS "名前空間 API"
+後で説明する種々の \fI/proc\fP ファイル以外に、名前空間 API として以下のシステムコールがある。
+.TP
+\fBclone\fP(2)
+\fBclone\fP(2) システムコールは新しいプロセスを作成する。 呼び出し時に \fIflags\fP 引き数で以下のリストにある
+\fBCLONE_NEW*\fP のフラグを一つ以上指定すると、 各フラグに対応する新しい名前空間が作成され、 子プロセスはこれらの名前空間のメンバーになる。
+(このシステムコールは名前空間とは関係のない機能も多数実装している。)
+.TP
+\fBsetns\fP(2)
+\fBsetns\fP(2) システムコールを使うと、呼び出したプロセスを既存の名前空間に参加させることができる。 参加する名前空間は、 以下で説明する
+\fI/proc/[pid]/ns\fP ファイルのいずれか一つを参照するファイルディスクリプタを使って指定する。
+.TP
+\fBunshare\fP(2)
+\fBunshare\fP(2) システムコールは、 呼び出したプロセスを新しい名前空間に移動する。 呼び出し時の \fIflags\fP
+引き数に以下のリストにある \fBCLONE_NEW*\fP フラグを一つ以上指定すると、 各フラグに対応する新しい名前空間が作成され、
+呼び出したプロセスがこれらの名前空間のメンバーになる。 (このシステムコールは名前空間とは関係のない機能も多数実装している。)
+.PP
+.\"
+.\" ==================== The /proc/[pid]/ns/ directory ====================
+.\"
+\fBclone\fP(2) と \fBunshare\fP(2) を使った新しい名前空間の作成のほとんどの場合で \fBCAP_SYS_ADMIN\fP
+ケーパビリティが必要である。 ユーザー名前空間は例外で、 Linux 3.8 以降ではユーザー名前空間を作成するのに特権が不要である。
+.SS "/proc/[pid]/ns/ ディレクトリ"
+.\" See commit 6b4e306aa3dc94a0545eb9279475b1ab6209a31f
+各プロセスには \fI/proc/[pid]/ns/\fP サブディレクトリがあり、 このサブディレクトリには \fBsetns\fP(2)
+での操作がサポートされている名前空間単位にエントリが存在する。
+
+.in +4n
+.nf
+$ \fBls \-l /proc/$$/ns\fP
+total 0
+lrwxrwxrwx. 1 mtk mtk 0 Jan 14 01:20 ipc \-> ipc:[4026531839]
+lrwxrwxrwx. 1 mtk mtk 0 Jan 14 01:20 mnt \-> mnt:[4026531840]
+lrwxrwxrwx. 1 mtk mtk 0 Jan 14 01:20 net \-> net:[4026531956]
+lrwxrwxrwx. 1 mtk mtk 0 Jan 14 01:20 pid \-> pid:[4026531836]
+lrwxrwxrwx. 1 mtk mtk 0 Jan 14 01:20 user \-> user:[4026531837]
+lrwxrwxrwx. 1 mtk mtk 0 Jan 14 01:20 uts \-> uts:[4026531838]
+.fi
+.in
+
+このディレクトリ内のファイルのいずれかをファイルシステムの他のどこかにバインドマウント (\fBmount\fP(2) 参照) することで、
+その名前空間のすべてのプロセスが終了した場合でも、 \fIpid\fP で指定したプロセスの対応する名前空間を保持することができる。
+
+このディレクトリ内のファイルのいずれか (またはこれらのファイルのいずれかにバインドマウントされたファイル) をオープンすると、 \fIpid\fP
+で指定されたプロセスの対応する名前空間に対するファイルハンドルが返される。 このファイルディスクリプタがオープンされている限り、
+その名前空間のすべてのプロセスが終了した場合であっても、 その名前空間は存在し続ける。 このファイルディスクリプタは \fBsetns\fP(2)
+に渡すことができる。
+
+Linux 3.7 以前では、これらのファイルはハードリンクとして見えていた。 Linux 3.8 以降では、これらはシンボリックリンクとして見える。
+2 つのプロセスが同じ名前空間に所属している場合、 これらのプロセスの \fI/proc/[pid]/ns/xxx\fP シンボリックリンクの inode
+番号は同じになる。 アプリケーションは、 \fBstat\fP(2) が返す \fIstat.st_ino\fP フィールドを使ってこれを確認することができる。
+シンボリックリンクの内容は、 以下の例にあるように、名前空間種別と inode 番号を含む文字列である。
+
+.in +4n
+.nf
+$ \fBreadlink /proc/$$/ns/uts\fP
+uts:[4026531838]
+.fi
+.in
+
+このサブディレクトリのファイルは以下のとおりである。
+.TP
+\fI/proc/[pid]/ns/ipc\fP (Linux 3.0 以降)
+このファイルはそのプロセスの IPC 名前空間の操作用である。
+.TP
+\fI/proc/[pid]/ns/mnt\fP (Linux 3.8 以降)
+このファイルはそのプロセスのマウント名前空間の操作用である。
+.TP
+\fI/proc/[pid]/ns/net\fP (Linux 3.0 以降)
+このファイルはそのプロセスのネットワーク名前空間の操作用である。
+.TP
+\fI/proc/[pid]/ns/pid\fP (Linux 3.8 以降)
+このファイルはそのプロセスの PID 名前空間の操作用である。
+.TP
+\fI/proc/[pid]/ns/user\fP (Linux 3.8 以降)
+このファイルはそのプロセスのユーザー名前空間の操作用である。
+.TP
+\fI/proc/[pid]/ns/uts\fP (Linux 3.0 以降)
+.\"
+.\" ==================== IPC namespaces ====================
+.\"
+このファイルはそのプロセスの UTS 名前空間の操作用である。
+.SS "IPC 名前空間 (CLONE_NEWIPC)"
+.\" commit 7eafd7c74c3f2e67c27621b987b28397110d643f
+.\" https://lwn.net/Articles/312232/
+IPC 名前空間は、 特定の IPC リソース、すなわち、System V IPC オブジェクト (\fBsvipc\fP(7) 参照)、(Linux
+2.6.30 以降では) POSIX メッセージキュー (\fBmq_overview\fP(7) 参照) を分離する。 これらの IPC
+機構に共通の特徴は、 IPC オブジェクトがファイルシステムのパス名以外の方法で識別されるという点である。
+
+各 IPC 名前空間はそれぞれ、 独自の System V IPC 識別子の集合と独自の POSIX メッセージキューファイルシステムを持つ。 IPC
+名前空間に作成されたオブジェクトは、 その名前空間のメンバーの他のすべてのプロセスにも見えるが、 他の IPC 名前空間のプロセスには見えない。
+
+以下の \fI/proc\fP インタフェースは各 IPC 名前空間で別のものとなる。
+.IP * 3
+\fI/proc/sys/fs/mqueue\fP の POSIX メッセージキューインタフェース。
+.IP *
+\fI/proc/sys/kernel\fP の System V IPC インタフェース。 すなわち、 \fImsgmax\fP, \fImsgmnb\fP,
+\fImsgmni\fP, \fIsem\fP, \fIshmall\fP, \fIshmmax\fP, \fIshmmni\fP, \fIshm_rmid_forced\fP。
+.IP *
+\fI/proc/sysvipc\fP の System V IPC インタフェース。
+.PP
+IPC 名前空間が破棄されたときに (すなわち、その名前空間のメンバーの最後のプロセスが終了したときに)、 その名前空間内のすべての IPC
+オブジェクトが自動的に破棄される。
+
+.\"
+.\" ==================== Network namespaces ====================
+.\"
+IPC 名前空間を使用するには、設定 \fBCONFIG_IPC_NS\fP が有効になったカーネルが必要である。
+.SS "ネットワーク名前空間 (CLONE_NEWNET)"
+.\" FIXME Add pointer to veth(4) page when it is eventually completed
+ネットワーク名前空間は、 ネットワークに関連するシステムリソースの分離を提供する。 分離されるリソースは、 ネットワークデバイス、 IPv4 と
+IPv6 のプロトコルスタック、 IP ルーティングテーブル、 ファイアウォール、 \fI/proc/net\fP ディレクトリ、
+\fI/sys/class/net\fP ディレクトリ、 (ソケットの) ポート番号などである。 物理ネットワークデバイスは 1
+つのネットワーク名前空間にのみ属すことができる。 仮想ネットワークデバイス ("veth") ペアは、
+ネットワーク名前空間間のトンネルを作成するのに使うことができるパイプ風の抽象概念で、
+別の名前空間に属す物理ネットワークデバイスへのブリッジを作成するのに使用できる。
+
+ネットワーク名前空間が解放されたときに (すなわち、その名前空間の最後のプロセスがしゅうりょうしたときに)、
+その名前空間に属していた物理ネットワークデバイスは初期ネットワーク名前空間に戻される (プロセスの親プロセスに戻されるわけではない)。
+
+.\"
+.\" ==================== Mount namespaces ====================
+.\"
+ネットワーク名前空間を使用するには、設定 \fBCONFIG_NET_NS\fP が有効になったカーネルが必要である。
+.SS "マウント名前空間 (CLONE_NEWNS)"
+マウント名前空間はファイルシステムのマウントポイントの集合を分離する。
+つまり、別のマウント名前空間のプロセスには別のファイルシステム階層が見えるということである。 マウント名前空間内のマウントの集合は
+\fBmount\fP(2) と \fBumount\fP(2) で変更される。
+
+\fI/proc/[pid]/mounts\fP ファイル (Linux 2.4.19 以降に存在) は、
+そのプロセスのマウント名前空間で現在マウントされている全ファイルシステムの一覧を表示する。 このファイルのフォーマットは \fBfstab\fP(5)
+に記載されている。 カーネルバージョン 2.6.15 以降では、このファイルをポーリングすることができる。
+すなわち、このファイルを読み出し用にオープンした後、 このファイルの変化 (ファイルシステムのマウントやアンマウント) が発生すると、
+\fBselect\fP(2) はファイルディスクリプタが読み出し可能になったと印を付け、 \fBpoll\fP(2) や \fBepoll_wait\fP(2)
+はファイルがエラー状態になったかのように印を付ける。
+
+\fI/proc/[pid]/mountstats\fP ファイル (Linux 2.6.17 以降に存在) は、 そのプロセスのマウントポイントに関する情報
+(統計情報、設定情報) を公開する。 このファイルはプロセスの所有者だけが読み出し可能である。 このファイルの各行は以下の形式である。
+.RS
+.in 12
+.nf
+
+device /dev/sda7 mounted on /home with fstype ext3 [statistics]
+( 1 ) ( 2 ) (3 ) (4)
+.fi
+.in
+
+各行のフィールドは以下のとおりである。
+.TP 5
+(1)
+マウントされているデバイス名 (もしくは、対応するデバイスがない場合は "nodevice")。
+.TP
+(2)
+ファイルシステムツリー内のマウントポイント。
+.TP
+(3)
+ファイルシステム種別
+.TP
+(4)
+統計情報と設定情報。 オプションフィールドである。 現在のところ (Linux 2.6.26 時点)、NFS
+ファイルシステムだけがこのフィールドで情報を公開している。
+.RE
+.\"
+.\" ==================== PID namespaces ====================
+.\"
+.SS "PID 名前空間 (CLONE_NEWPID)"
+.\"
+.\" ==================== User namespaces ====================
+.\"
+\fBpid_namespaces\fP(7) 参照。
+.SS "ユーザー名前空間 (CLONE_NEWUSER)"
+.\"
+.\" ==================== UTS namespaces ====================
+.\"
+\fBuser_namespaces\fP(7) 参照。
+.SS "UTS 名前空間 (CLONE_NEWUTS)"
+UTS 名前空間は、 ホスト名と NIS ドメイン名の 2 つのシステム識別子を分離する。 これらの識別子は \fBsethostname\fP(2) と
+\fBsetdomainname\fP(2) を使って設定でき、 \fBuname\fP(2), \fBgethostname\fP(2),
+\fBgetdomainname\fP(2) を使って取得できる。
+
+UTS 名前空間を使用するには、設定 \fBCONFIG_UTS_NS\fP が有効になったカーネルが必要である。
+.SH 準拠
+名前空間は Linux 独自の機能である。
+.SH 例
+\fBuser_namespaces\fP(7) 参照。
+.SH 関連項目
+\fBnsenter\fP(1), \fBreadlink\fP(1), \fBunshare\fP(1), \fBclone\fP(2), \fBsetns\fP(2),
+\fBunshare\fP(2), \fBproc\fP(5), \fBcredentials\fP(7), \fBcapabilities\fP(7),
+\fBpid_namespaces\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/ に書かれている。
元のファンアウトアルゴリズムが backlog ソケットを選択していれば、 パケットは次の利用可能なソケットにロールオーバーされる。
.TP
\fBPACKET_LOSS\fP (\fBPACKET_TX_RING\fP で使用)
-When a malformed packet is encountered on a transmit ring, the default is to
-reset its \fItp_status\fP to \fBTP_STATUS_WRONG_FORMAT\fP and abort the
-transmission immediately. The malformed packet blocks itself and
-subsequently enqueued packets from being sent. The format error must be
-fixed, the associated \fItp_status\fP reset to \fBTP_STATUS_SEND_REQUEST\fP, and
-the transmission process restarted via \fBsend\fP(2). However, if
-\fBPACKET_LOSS\fP is set, any malformed packet will be skipped, its
-\fItp_status\fP reset to \fBTP_STATUS_AVAILABLE\fP, and the transmission process
-continued.
+送信リングで不正な形式のパケットに遭遇した場合、 デフォルトではそのリングの \fItp_status\fP を
+\fBTP_STATUS_WRONG_FORMAT\fP に戻し、その送信を直ちに中止する。
+不正な形式のパケットにより、そのパケット自身とその以降にキューに入れられたパケットの送信がブロックされる。形式エラーを修正し、関連する
+\fItp_status\fP を \fBTP_STATUS_SEND_REQUEST\fP に設定し直し、\fBsend\fP(2)
+を使って送信処理を再開しなければならない。 しかしながら、 \fBPACKET_LOSS\fP がセットされている場合、
+不正な形式のパケットはすべてスキップされ、 その送信リングの \fItp_status\fP は \fBTP_STATUS_AVAILABLE\fP
+に設定し直され、送信処理は継続される。
.TP
\fBPACKET_RESERVE\fP (\fBPACKET_RX_RING\fP で使用)
デフォルトでは、パケット受信リングはメタデータ構造体とアライメント用のパディングの直後にパケットを書き込む。
物理層のプロトコルに関する記述は \fI<linux/if_ether.h>\fP インクルードファイルにある。
-The Linux kernel source tree. \fI/Documentation/networking/filter.txt\fP
-describes how to apply Berkeley Packet Filters to packet sockets.
-\fI/tools/testing/selftests/net/psock_tpacket.c\fP contains example source code
-for all available versions of \fBPACKET_RX_RING\fP and \fBPACKET_TX_RING\fP.
+Linux カーネルのソースツリー。 \fI/Documentation/networking/filter.txt\fP には Berkeley
+Packet Filters をパケットソケットにどのように適用するかの説明がある。
+\fI/tools/testing/selftests/net/psock_tpacket.c\fP には、 \fBPACKET_RX_RING\fP と
+\fBPACKET_TX_RING\fP の利用可能なすべてのバージョンのサンプルソースコードがある。
.SH この文書について
この man ページは Linux \fIman\-pages\fP プロジェクトのリリース 3.76 の一部
である。プロジェクトの説明とバグ報告に関する情報は
.TP
\fIshm_ctime\fP
最後に \fBshmctl\fP(2) システムコールを行なって、 \fIshmid_ds\fP 構造体を変更した時間。
-.SS "IPC namespaces"
-For a discussion of the interaction of System V IPC objects and IPC
-namespaces, see \fBnamespaces\fP(7).
+.SS "IPC 名前空間"
+System V IPC オブジェクトと IPC 名前空間の相互の影響に関する議論は \fBnamespaces\fP(7) を参照。
.SH 関連項目
\fBipcmk\fP(1), \fBipcrm\fP(1), \fBipcs\fP(1), \fBipc\fP(2), \fBmsgctl\fP(2), \fBmsgget\fP(2),
\fBmsgrcv\fP(2), \fBmsgsnd\fP(2), \fBsemctl\fP(2), \fBsemget\fP(2), \fBsemop\fP(2),
○:LDP man-pages:3.76:2010/09/20:chroot:2:2015/01/05::ysato444@yahoo.co.jp:Yuichi SATO:
○:LDP man-pages:3.76:2013/12/28:clock_getres:2:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2013/12/28:clock_gettime:2:clock_getres:2:
-â\98\86:LDP man-pages:3.68=>3.76:2014/12/31:clock_nanosleep:2:2014/06/08::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/12/31:clock_nanosleep:2:2015/01/07::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2013/12/28:clock_settime:2:clock_getres:2:
-â\98\86:LDP man-pages:3.68=>3.76:2014/09/21:clone:2:2014/06/08::amotoki@gmail.com:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/09/21:clone:2:2015/01/07::amotoki@gmail.com:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2014/09/21:clone2:2:clone:2:
○:LDP man-pages:3.76:2013/12/30:close:2:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
○:LDP man-pages:3.76:2014/09/06:connect:2:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2014/12/31:creat:2:open:2:
-â\98\86:LDP man-pages:3.65=>3.76:2014/05/10:create_module:2:2014/04/24::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/05/10:create_module:2:2015/01/07::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
☆:LDP man-pages:3.41=>3.76:2014/05/10:delete_module:2:2006/07/30::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
-â\98\86:LDP man-pages:3.68=>3.76:2014/07/08:dup:2:2014/06/08::amotoki@gmail.com:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/07/08:dup:2:2015/01/07::amotoki@gmail.com:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2014/07/08:dup2:2:dup:2:
＠:LDP man-pages:3.76:2014/07/08:dup3:2:dup:2:
○:LDP man-pages:3.76:2012/04/15:epoll_create:2:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2012/04/15:epoll_create1:2:epoll_create:2:
-â\98\86:LDP man-pages:3.68=>3.76:2014/12/31:epoll_ctl:2:2014/06/08::amotoki@gmail.com:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/12/31:epoll_ctl:2:2015/01/07::amotoki@gmail.com:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2014/08/19:epoll_pwait:2:epoll_wait:2:
○:LDP man-pages:3.76:2014/08/19:epoll_wait:2:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.76:2014/07/08:eventfd:2:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2014/07/08:eventfd2:2:eventfd:2:
-â\98\86:LDP man-pages:3.68=>3.76:2014/10/02:execve:2:2014/06/08::amotoki@gmail.com:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/10/02:execve:2:2015/01/07::amotoki@gmail.com:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2010/09/20:exit:2:_exit:2:
○:LDP man-pages:3.76:2008/11/27:exit_group:2:2015/01/05::ysato444@yahoo.co.jp:Yuichi SATO:
＠:LDP man-pages:3.76:2014/08/19:faccessat:2:access:2:
＠:LDP man-pages:3.76:2014/12/31:fadvise64:2:posix_fadvise:2:
＠:LDP man-pages:3.76:2014/12/31:fadvise64_64:2:posix_fadvise:2:
-â\98\86:LDP man-pages:3.65=>3.76:2014/07/08:fallocate:2:2014/04/27::amotoki@gmail.com:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/07/08:fallocate:2:2015/01/07::amotoki@gmail.com:Akihiro MOTOKI:
×:LDP man-pages:3.76:2014/10/02:fanotify_init:2:::::
×:LDP man-pages:3.76:2014/10/02:fanotify_mark:2:::::
＠:LDP man-pages:3.76:2013/02/12:fattach:2:unimplemented:2:
＠:LDP man-pages:3.76:2014/08/19:getgroups32:2:getgroups:2:
＠:LDP man-pages:3.76:2010/09/20:gethostid:2:gethostid:3:
○:LDP man-pages:3.76:2014/08/19:gethostname:2:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
-â\98\86:LDP man-pages:3.68=>3.76:2014/07/08:getitimer:2:2014/06/08::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/07/08:getitimer:2:2015/01/07::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2013/02/12:getmsg:2:unimplemented:2:
○:LDP man-pages:3.76:2014/08/19:getpagesize:2:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.76:2013/02/12:getpeername:2:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
○:LDP man-pages:3.76:2014/09/21:getpid:2:2015/01/05::suto@av.crl.sony.co.jp:SUTO, Mitsuaki:
＠:LDP man-pages:3.76:2013/02/12:getpmsg:2:unimplemented:2:
＠:LDP man-pages:3.76:2014/09/21:getppid:2:getpid:2:
-â\98\86:LDP man-pages:3.68=>3.76:2014/08/19:getpriority:2:2014/06/08::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/08/19:getpriority:2:2015/01/07::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2010/11/22:getresgid:2:getresuid:2:
＠:LDP man-pages:3.76:2010/11/22:getresgid32:2:getresgid:2:
○:LDP man-pages:3.76:2010/11/22:getresuid:2:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
☆:LDP man-pages:3.41=>3.76:2014/05/10:init_module:2:2006/07/30::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2012/12/31:inl:2:outb:2:
＠:LDP man-pages:3.76:2012/12/31:inl_p:2:outb:2:
-â\98\86:LDP man-pages:3.68=>3.76:2014/07/08:inotify_add_watch:2:2014/06/08::amotoki@gmail.com:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/07/08:inotify_add_watch:2:2015/01/07::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.76:2014/03/28:inotify_init:2:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2014/03/28:inotify_init1:2:inotify_init:2:
○:LDP man-pages:3.76:2010/10/15:inotify_rm_watch:2:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
○:LDP man-pages:3.76:2012/10/16:ipc:2:2015/01/05::hanataka@abyss.rim.or.jp:HANATAKA Shinya:
＠:LDP man-pages:3.76:2013/02/12:isastream:2:unimplemented:2:
○:LDP man-pages:3.76:2013/12/08:kcmp:2:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
-â\98\86:LDP man-pages:3.68=>3.76:2014/08/19:kexec_load:2:2014/06/08::amotoki@gmail.com:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/08/19:kexec_load:2:2015/01/07::amotoki@gmail.com:Akihiro MOTOKI:
×:LDP man-pages:3.76:2014/01/22:keyctl:2:::::
○:LDP man-pages:3.76:2013/09/17:kill:2:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
○:LDP man-pages:3.76:2010/09/20:killpg:2:2015/01/05::ysato444@yahoo.co.jp:Yuichi SATO:
＠:LDP man-pages:3.76:2014/08/19:lchown:2:chown:2:
＠:LDP man-pages:3.76:2014/08/19:lchown32:2:lchown:2:
＠:LDP man-pages:3.76:2014/04/06:lgetxattr:2:getxattr:2:
-â\98\86:LDP man-pages:3.65=>3.76:2014/08/19:link:2:2014/04/24::ysato444@yahoo.co.jp:Yuichi SATO:
+â\97\8b:LDP man-pages:3.76:2014/08/19:link:2:2015/01/07::ysato444@yahoo.co.jp:Yuichi SATO:
＠:LDP man-pages:3.76:2014/08/19:linkat:2:link:2:
○:LDP man-pages:3.76:2014/05/10:listen:2:2015/01/05::argrath@ub32.org:Kentaro Shirakata:
○:LDP man-pages:3.76:2014/02/06:listxattr:2:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2013/02/12:lock:2:unimplemented:2:
○:LDP man-pages:3.76:2004/06/17:lookup_dcookie:2:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2014/02/06:lremovexattr:2:removexattr:2:
-â\98\86:LDP man-pages:3.68=>3.76:2014/06/13:lseek:2:2014/06/08::amotoki@gmail.com:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/06/13:lseek:2:2015/01/07::amotoki@gmail.com:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2014/02/06:lsetxattr:2:setxattr:2:
＠:LDP man-pages:3.76:2014/08/19:lstat:2:stat:2:
＠:LDP man-pages:3.76:2014/08/19:lstat64:2:lstat:2:
-â\98\86:LDP man-pages:3.68=>3.76:2014/12/31:madvise:2:2014/06/08::amotoki@gmail.com:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/12/31:madvise:2:2015/01/07::amotoki@gmail.com:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2013/02/12:madvise1:2:unimplemented:2:
○:LDP man-pages:3.76:2014/05/10:mbind:2:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
○:LDP man-pages:3.76:2012/08/01:migrate_pages:2:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
×:LDP man-pages:3.76:2013/02/13:perfmonctl:2:::::
○:LDP man-pages:3.76:2014/04/15:personality:2:2015/01/05::argrath@ub32.org:Kentaro Shirakata:
＠:LDP man-pages:3.76:2013/02/12:phys:2:unimplemented:2:
-â\98\86:LDP man-pages:3.68=>3.76:2014/07/08:pipe:2:2014/06/08::amotoki@gmail.com:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/07/08:pipe:2:2015/01/07::amotoki@gmail.com:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2014/07/08:pipe2:2:pipe:2:
○:LDP man-pages:3.76:2012/07/13:pivot_root:2:2015/01/05::nakano@apm.seikei.ac.jp:NAKANO Takeo:
-â\98\86:LDP man-pages:3.68=>3.76:2014/09/06:poll:2:2014/06/08::amotoki@gmail.com:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/09/06:poll:2:2015/01/07::amotoki@gmail.com:Akihiro MOTOKI:
☆:LDP man-pages:3.68=>3.76:2014/12/31:posix_fadvise:2:2014/06/08::amotoki@gmail.com:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2014/09/06:ppoll:2:poll:2:
☆:LDP man-pages:3.40=>3.76:2014/12/31:prctl:2:2012/05/26::amotoki@gmail.com:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2013/06/21:pwrite:2:pread:2:
＠:LDP man-pages:3.76:2013/06/21:pwrite64:2:pwrite:2:
＠:LDP man-pages:3.76:2014/10/15:pwritev:2:readv:2:
-â\98\86:LDP man-pages:3.65=>3.76:2014/05/10:query_module:2:2014/04/24::amotoki@gmail.com:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/05/10:query_module:2:2015/01/07::amotoki@gmail.com:Akihiro MOTOKI:
×:LDP man-pages:3.76:2010/06/16:quotactl:2:::::
☆:LDP man-pages:3.65=>3.76:2014/05/04:read:2:2014/04/24::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
○:LDP man-pages:3.76:2014/03/15:readahead:2:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
○:LDP man-pages:3.76:2013/06/21:readdir:2:2015/01/05::hanataka@abyss.rim.or.jp:HANATAKA Shinya:
-â\98\86:LDP man-pages:3.68=>3.76:2014/10/15:readlink:2:2014/06/08::amotoki@gmail.com:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/10/15:readlink:2:2015/01/07::amotoki@gmail.com:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2014/10/15:readlinkat:2:readlink:2:
-â\98\86:LDP man-pages:3.68=>3.76:2014/10/15:readv:2:2014/06/08::amotoki@gmail.com:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/10/15:readv:2:2015/01/07::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.76:2014/09/21:reboot:2:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.76:2014/08/19:recv:2:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2014/08/19:recvfrom:2:recv:2:
＠:LDP man-pages:3.76:2014/05/11:sched_getparam:2:sched_setparam:2:
＠:LDP man-pages:3.76:2014/10/02:sched_getscheduler:2:sched_setscheduler:2:
○:LDP man-pages:3.76:2014/04/28:sched_rr_get_interval:2:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
-â\98\86:LDP man-pages:3.68=>3.76:2014/12/31:sched_setaffinity:2:2014/06/08::amotoki@gmail.com:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/12/31:sched_setaffinity:2:2015/01/07::amotoki@gmail.com:Akihiro MOTOKI:
×:LDP man-pages:3.76:2014/10/02:sched_setattr:2:::::
○:LDP man-pages:3.76:2014/05/11:sched_setparam:2:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
☆:LDP man-pages:3.65=>3.76:2014/10/02:sched_setscheduler:2:2014/04/24::amotoki@gmail.com:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2014/04/08:setcontext:2:getcontext:3:
＠:LDP man-pages:3.76:2012/10/25:setdomainname:2:getdomainname:2:
＠:LDP man-pages:3.76:2014/09/21:setegid:2:seteuid:2:
-â\98\86:LDP man-pages:3.68=>3.76:2014/09/21:seteuid:2:2014/06/08::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/09/21:seteuid:2:2015/01/07::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
○:LDP man-pages:3.76:2013/08/08:setfsgid:2:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2013/08/08:setfsgid32:2:setfsgid:2:
○:LDP man-pages:3.76:2013/08/08:setfsuid:2:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2013/08/08:setfsuid32:2:setfsuid:2:
-â\98\86:LDP man-pages:3.68=>3.76:2014/09/21:setgid:2:2014/06/08::amotoki@gmail.com:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/09/21:setgid:2:2015/01/07::amotoki@gmail.com:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2014/09/21:setgid32:2:setgid:2:
＠:LDP man-pages:3.76:2014/08/19:setgroups:2:getgroups:2:
＠:LDP man-pages:3.76:2014/08/19:setgroups32:2:setgroups:2:
＠:LDP man-pages:3.76:2010/09/20:sethostid:2:gethostid:3:
＠:LDP man-pages:3.76:2014/08/19:sethostname:2:gethostname:2:
＠:LDP man-pages:3.76:2014/07/08:setitimer:2:getitimer:2:
-â\98\86:LDP man-pages:3.68=>3.76:2014/09/21:setns:2:2014/06/08::amotoki@gmail.com:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/09/21:setns:2:2015/01/07::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.76:2014/01/07:setpgid:2:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2014/01/07:setpgrp:2:setpgid:2:
＠:LDP man-pages:3.76:2014/08/19:setpriority:2:getpriority:2:
＠:LDP man-pages:3.76:2014/09/21:setregid32:2:setregid:2:
＠:LDP man-pages:3.76:2014/09/21:setresgid:2:setresuid:2:
＠:LDP man-pages:3.76:2014/09/21:setresgid32:2:setresgid:2:
-â\98\86:LDP man-pages:3.68=>3.76:2014/09/21:setresuid:2:2014/06/08::amotoki@gmail.com:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/09/21:setresuid:2:2015/01/07::amotoki@gmail.com:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2014/09/21:setresuid32:2:setresuid:2:
-â\98\86:LDP man-pages:3.68=>3.76:2014/09/21:setreuid:2:2014/06/08::amotoki@gmail.com:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/09/21:setreuid:2:2015/01/07::amotoki@gmail.com:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2014/09/21:setreuid32:2:setreuid:2:
＠:LDP man-pages:3.76:2014/10/02:setrlimit:2:getrlimit:2:
-â\98\86:LDP man-pages:3.68=>3.76:2014/12/31:setsid:2:2014/06/08::ysato444@yahoo.co.jp:Yuichi SATO:
+â\97\8b:LDP man-pages:3.76:2014/12/31:setsid:2:2015/01/07::ysato444@yahoo.co.jp:Yuichi SATO:
＠:LDP man-pages:3.76:2014/04/28:setsockopt:2:getsockopt:2:
＠:LDP man-pages:3.76:2012/04/26:settimeofday:2:gettimeofday:2:
-â\98\86:LDP man-pages:3.68=>3.76:2014/09/21:setuid:2:2014/06/08::amotoki@gmail.com:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/09/21:setuid:2:2015/01/07::amotoki@gmail.com:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2014/09/21:setuid32:2:setuid:2:
○:LDP man-pages:3.76:2008/12/03:setup:2:2015/01/05::argrath@ub32.org:Kentaro Shirakata:
○:LDP man-pages:3.76:2014/02/06:setxattr:2:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
-â\98\86:LDP man-pages:3.68=>3.76:2014/12/31:sgetmask:2:2014/06/08::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/12/31:sgetmask:2:2015/01/07::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2014/07/08:shmat:2:shmop:2:
○:LDP man-pages:3.76:2014/02/07:shmctl:2:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2014/07/08:shmdt:2:shmop:2:
-â\98\86:LDP man-pages:3.65=>3.76:2014/10/02:shmget:2:2014/04/24::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
-â\98\86:LDP man-pages:3.65=>3.76:2014/07/08:shmop:2:2014/04/24::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/10/02:shmget:2:2015/01/07::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/07/08:shmop:2:2015/01/07::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
○:LDP man-pages:3.76:2012/09/06:shutdown:2:2015/01/05::argrath@ub32.org:Kentaro Shirakata:
-â\98\86:LDP man-pages:3.68=>3.76:2014/12/31:sigaction:2:2014/06/08::amotoki@gmail.com:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/12/31:sigaction:2:2015/01/07::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.76:2010/09/26:sigaltstack:2:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
○:LDP man-pages:3.76:2014/08/19:signal:2:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.76:2014/07/08:signalfd:2:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
☆:LDP man-pages:3.68=>3.76:2014/12/31:sigreturn:2:2014/06/08::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
○:LDP man-pages:3.76:2013/04/19:sigsuspend:2:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2014/08/19:sigtimedwait:2:sigwaitinfo:2:
-â\98\86:LDP man-pages:3.68=>3.76:2014/08/19:sigwaitinfo:2:2014/06/08::amotoki@gmail.com:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/08/19:sigwaitinfo:2:2015/01/07::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.76:2013/12/31:socket:2:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.76:2012/10/16:socketcall:2:2015/01/05::hanataka@abyss.rim.or.jp:HANATAKA Shinya:
○:LDP man-pages:3.76:2008/10/11:socketpair:2:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
-â\98\86:LDP man-pages:3.68=>3.76:2014/12/31:splice:2:2014/06/08::amotoki@gmail.com:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/12/31:splice:2:2015/01/07::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.76:2012/08/05:spu_create:2:2015/01/05::amotoki@gmail.com:Akihiro Motoki:
○:LDP man-pages:3.76:2012/08/05:spu_run:2:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2014/12/31:ssetmask:2:sgetmask:2:
○:LDP man-pages:3.76:2014/08/19:stat:2:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2014/08/19:stat64:2:stat:2:
-â\98\86:LDP man-pages:3.68=>3.76:2014/06/13:statfs:2:2014/06/08::amotoki@gmail.com:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/06/13:statfs:2:2015/01/07::amotoki@gmail.com:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2014/06/13:statfs64:2:statfs:2:
＠:LDP man-pages:3.76:2013/09/26:statvfs:2:statvfs:3:
○:LDP man-pages:3.76:2014/05/10:stime:2:2015/01/05::argrath@ub32.org:Kentaro Shirakata:
×:LDP man-pages:3.76:2012/07/13:subpage_prot:2:::::
＠:LDP man-pages:3.76:2014/05/28:swapoff:2:swapon:2:
○:LDP man-pages:3.76:2014/05/28:swapon:2:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
-â\98\86:LDP man-pages:3.65=>3.76:2014/08/19:symlink:2:2014/04/24::ysato444@yahoo.co.jp:Yuichi SATO:
+â\97\8b:LDP man-pages:3.76:2014/08/19:symlink:2:2015/01/07::ysato444@yahoo.co.jp:Yuichi SATO:
＠:LDP man-pages:3.76:2014/08/19:symlinkat:2:symlink:2:
○:LDP man-pages:3.76:2014/08/19:sync:2:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
-â\98\86:LDP man-pages:3.68=>3.76:2014/08/19:sync_file_range:2:2014/06/08::amotoki@gmail.com:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/08/19:sync_file_range:2:2015/01/07::amotoki@gmail.com:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2014/08/19:sync_file_range2:2:sync_file_range:2:
＠:LDP man-pages:3.76:2014/08/19:syncfs:2:sync:2:
○:LDP man-pages:3.76:2014/12/31:syscall:2:2015/01/05::ysato@h4.dion.ne.jp:Yuichi SATO:
○:LDP man-pages:3.76:2010/06/27:sysfs:2:2015/01/05::ysato@h4.dion.ne.jp:Yuichi SATO:
○:LDP man-pages:3.76:2014/08/19:sysinfo:2:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
☆:LDP man-pages:3.68=>3.76:2014/07/08:syslog:2:2014/06/08::amotoki@gmail.com:Akihiro MOTOKI:
-â\98\86:LDP man-pages:3.68=>3.76:2014/12/31:tee:2:2014/06/08::amotoki@gmail.com:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/12/31:tee:2:2015/01/07::amotoki@gmail.com:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2014/12/31:tgkill:2:tkill:2:
○:LDP man-pages:3.76:2011/09/09:time:2:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
×:LDP man-pages:3.76:2014/08/19:timer_create:2:::::
＠:LDP man-pages:3.76:2014/02/26:umount2:2:umount:2:
○:LDP man-pages:3.76:2014/09/21:uname:2:2015/01/05::ysato@h4.dion.ne.jp:Yuichi SATO:
○:LDP man-pages:3.76:2013/02/12:unimplemented:2:2015/01/05::hanataka@abyss.rim.or.jp:HANATAKA Shinya:
-â\98\86:LDP man-pages:3.68=>3.76:2014/08/19:unlink:2:2014/06/08::amotoki@gmail.com:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/08/19:unlink:2:2015/01/07::amotoki@gmail.com:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2014/08/19:unlinkat:2:unlink:2:
-â\98\86:LDP man-pages:3.68=>3.76:2014/09/21:unshare:2:2014/06/08::amotoki@gmail.com:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/09/21:unshare:2:2015/01/07::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.76:2005/01/09:uselib:2:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
○:LDP man-pages:3.76:2003/08/04:ustat:2:2015/01/05::ysato444@yahoo.co.jp:Yuichi SATO:
○:LDP man-pages:3.76:2014/08/19:utime:2:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
○:LDP man-pages:3.76:2007/07/26:vhangup:2:2015/01/05::ysato444@yahoo.co.jp:Yuichi SATO:
○:LDP man-pages:3.76:2009/02/20:vm86:2:2015/01/05::ysato444@yahoo.co.jp:Yuichi SATO:
＠:LDP man-pages:3.76:2009/02/20:vm86old:2:vm86:2:
-â\98\86:LDP man-pages:3.68=>3.76:2014/10/02:vmsplice:2:2014/06/08::amotoki@gmail.com:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/10/02:vmsplice:2:2015/01/07::amotoki@gmail.com:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2013/02/12:vserver:2:unimplemented:2:
○:LDP man-pages:3.76:2014/08/19:wait:2:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2012/09/23:wait3:2:wait4:2:
＠:LDP man-pages:3.76:2010/08/29:error_print_progname:3:error:3:
＠:LDP man-pages:3.76:2013/12/30:errx:3:err:3:
＠:LDP man-pages:3.76:2008/07/17:etext:3:end:3:
-â\98\86:LDP man-pages:3.68=>3.76:2014/07/08:ether_aton:3:2014/06/08::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/07/08:ether_aton:3:2015/01/07::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2014/07/08:ether_aton_r:3:ether_aton:3:
＠:LDP man-pages:3.76:2014/07/08:ether_hostton:3:ether_aton:3:
＠:LDP man-pages:3.76:2014/07/08:ether_line:3:ether_aton:3:
＠:LDP man-pages:3.76:2013/08/06:frexpl:3:frexp:3:
＠:LDP man-pages:3.76:2014/01/11:fscanf:3:scanf:3:
○:LDP man-pages:3.76:2014/05/28:fseek:3:2015/01/05::nakano@apm.seikei.ac.jp:NAKANO Takeo:
-â\98\86:LDP man-pages:3.68=>3.76:2014/10/02:fseeko:3:2014/06/08::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/10/02:fseeko:3:2015/01/07::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2014/05/28:fsetpos:3:fseek:3:
＠:LDP man-pages:3.76:2013/09/26:fstatvfs:3:statvfs:3:
＠:LDP man-pages:3.76:2014/05/28:ftell:3:fseek:3:
＠:LDP man-pages:3.76:2014/03/18:fts_open:3:fts:3:
＠:LDP man-pages:3.76:2014/03/18:fts_read:3:fts:3:
＠:LDP man-pages:3.76:2014/03/18:fts_set:3:fts:3:
-â\98\86:LDP man-pages:3.68=>3.76:2014/12/31:ftw:3:2014/06/08::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/12/31:ftw:3:2015/01/07::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2014/08/19:funlockfile:3:flockfile:3:
※:LDP man-pages:3.76:2014/01/24:futimens:3:utimensat:2:
○:LDP man-pages:3.76:2013/10/29:futimes:3:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
○:LDP man-pages:3.76:2002/02/28:getfsent:3:2015/01/05::nakano@apm.seikei.ac.jp:NAKANO Takeo:
＠:LDP man-pages:3.76:2002/02/28:getfsfile:3:getfsent:3:
＠:LDP man-pages:3.76:2002/02/28:getfsspec:3:getfsent:3:
-â\98\86:LDP man-pages:3.68=>3.76:2014/10/02:getgrent:3:2014/06/08::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/10/02:getgrent:3:2015/01/07::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
○:LDP man-pages:3.76:2014/08/19:getgrent_r:3:2015/01/05::ysato444@yahoo.co.jp:Yuichi SATO:
＠:LDP man-pages:3.76:2014/08/19:getgrgid:3:getgrnam:3:
＠:LDP man-pages:3.76:2014/08/19:getgrgid_r:3:getgrnam:3:
＠:LDP man-pages:3.76:2013/04/19:getlogin_r:3:getlogin:3:
○:LDP man-pages:3.76:2009/09/15:getmntent:3:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2009/09/15:getmntent_r:3:getmntent:3:
-â\98\86:LDP man-pages:3.67=>3.76:2014/05/28:getnameinfo:3:2014/06/04::amotoki@gmail.com:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/05/28:getnameinfo:3:2015/01/07::amotoki@gmail.com:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2008/08/19:getnetbyaddr:3:getnetent:3:
＠:LDP man-pages:3.76:2010/09/10:getnetbyaddr_r:3:getnetent_r:3:
＠:LDP man-pages:3.76:2008/08/19:getnetbyname:3:getnetent:3:
＠:LDP man-pages:3.76:2012/08/26:gnu_get_libc_release:3:gnu_get_libc_version:3:
○:LDP man-pages:3.76:2012/08/26:gnu_get_libc_version:3:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
○:LDP man-pages:3.76:2008/06/14:grantpt:3:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
-×:LDP man-pages:3.76:2014/03/30:group_member:3:::::
+○:LDP man-pages:3.76:2014/03/30:group_member:3:2015/01/07::amotoki@gmail.com:Akihiro Motoki:
○:LDP man-pages:3.76:2007/07/26:gsignal:3:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2014/03/11:h_errno:3:gethostbyname:3:
○:LDP man-pages:3.76:2012/04/23:hash:3:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2014/03/18:iscntrl_l:3:isalpha:3:
＠:LDP man-pages:3.76:2014/03/18:isdigit:3:isalpha:3:
＠:LDP man-pages:3.76:2014/03/18:isdigit_l:3:isalpha:3:
-×:LDP man-pages:3.76:2014/03/13:isfdtype:3:::::
+○:LDP man-pages:3.76:2014/03/13:isfdtype:3:2015/01/07::amotoki@gmail.com:Akihiro Motoki:
＠:LDP man-pages:3.76:2013/08/06:isfinite:3:fpclassify:3:
＠:LDP man-pages:3.76:2014/03/18:isgraph:3:isalpha:3:
＠:LDP man-pages:3.76:2014/03/18:isgraph_l:3:isalpha:3:
＠:LDP man-pages:3.76:2013/08/26:lroundf:3:lround:3:
＠:LDP man-pages:3.76:2013/08/26:lroundl:3:lround:3:
○:LDP man-pages:3.76:1999/09/27:lsearch:3:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
-â\98\86:LDP man-pages:3.68=>3.76:2014/08/19:lseek64:3:2014/06/08::ysato444@yahoo.co.jp:Yuichi SATO:
+â\97\8b:LDP man-pages:3.76:2014/08/19:lseek64:3:2015/01/07::ysato444@yahoo.co.jp:Yuichi SATO:
＠:LDP man-pages:3.76:2013/10/29:lutimes:3:futimes:3:
＠:LDP man-pages:3.76:2014/05/28:major:3:makedev:3:
○:LDP man-pages:3.76:2014/05/28:makecontext:3:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
○:LDP man-pages:3.76:2012/04/26:mpool:3:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
※:LDP man-pages:3.76:2014/01/11:mprobe:3:mcheck:3:
○:LDP man-pages:3.76:2014/06/13:mq_close:3:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
-â\98\86:LDP man-pages:3.68=>3.76:2014/10/02:mq_getattr:3:2014/06/08::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/10/02:mq_getattr:3:2015/01/07::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
○:LDP man-pages:3.76:2014/04/06:mq_notify:3:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
-â\98\86:LDP man-pages:3.68=>3.76:2014/12/31:mq_open:3:2014/06/08::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/12/31:mq_open:3:2015/01/07::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
○:LDP man-pages:3.76:2014/06/03:mq_receive:3:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
○:LDP man-pages:3.76:2014/06/03:mq_send:3:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2014/10/02:mq_setattr:3:mq_getattr:3:
＠:LDP man-pages:3.76:2014/08/19:passwd2des:3:xcrypt:3:
＠:LDP man-pages:3.76:2014/05/28:pathconf:3:fpathconf:3:
＠:LDP man-pages:3.76:2013/04/19:pclose:3:popen:3:
-â\98\86:LDP man-pages:3.67=>3.76:2014/05/28:perror:3:2014/06/04::amotoki@gmail.com:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/05/28:perror:3:2015/01/07::amotoki@gmail.com:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2013/09/26:pmap_getmaps:3:rpc:3:
＠:LDP man-pages:3.76:2013/09/26:pmap_getport:3:rpc:3:
＠:LDP man-pages:3.76:2013/09/26:pmap_rmtcall:3:rpc:3:
○:LDP man-pages:3.76:2008/11/27:pthread_join:3:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.76:2014/05/13:pthread_kill:3:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.76:2014/05/13:pthread_kill_other_threads_np:3:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
-※:LDP man-pages:3.76:2014/10/15:pthread_rwlockattr_getkind_np:3:pthread_rwlockattr_setkind_np:3:
-×:LDP man-pages:3.76:2014/10/15:pthread_rwlockattr_setkind_np:3:::::
+＠:LDP man-pages:3.76:2014/10/15:pthread_rwlockattr_getkind_np:3:pthread_rwlockattr_setkind_np:3:
+○:LDP man-pages:3.76:2014/10/15:pthread_rwlockattr_setkind_np:3:2015/01/07::amotoki@gmail.com:Akihiro Motoki:
○:LDP man-pages:3.76:2014/05/13:pthread_self:3:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.76:2014/05/23:pthread_setaffinity_np:3:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.76:2014/05/13:pthread_setcancelstate:3:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2014/12/31:siggetmask:3:sigvec:3:
＠:LDP man-pages:3.76:2010/09/20:sighold:3:sigset:3:
＠:LDP man-pages:3.76:2010/09/20:sigignore:3:sigset:3:
-â\98\86:LDP man-pages:3.68=>3.76:2014/06/13:siginterrupt:3:2014/06/08::hanataka@abyss.rim.or.jp:HANATAKA Shinya:
+â\97\8b:LDP man-pages:3.76:2014/06/13:siginterrupt:3:2015/01/07::hanataka@abyss.rim.or.jp:HANATAKA Shinya:
＠:LDP man-pages:3.76:2014/04/14:sigisemptyset:3:sigsetops:3:
＠:LDP man-pages:3.76:2014/04/14:sigismember:3:sigsetops:3:
＠:LDP man-pages:3.76:2009/01/13:siglongjmp:3:longjmp:3:
＠:LDP man-pages:3.76:2014/12/31:sigsetmask:3:sigvec:3:
○:LDP man-pages:3.76:2014/04/14:sigsetops:3:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2010/09/26:sigstack:3:sigaltstack:2:
-â\98\86:LDP man-pages:3.68=>3.76:2014/12/31:sigvec:3:2014/06/08::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/12/31:sigvec:3:2015/01/07::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
○:LDP man-pages:3.76:2013/12/16:sigwait:3:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.76:2013/12/16:sin:3:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
○:LDP man-pages:3.76:2013/12/23:sincos:3:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
○:LDP man-pages:3.76:2013/07/22:ttyslot:3:2015/01/05::ysato444@yahoo.co.jp:Yuichi SATO:
＠:LDP man-pages:3.76:2014/05/28:twalk:3:tsearch:3:
＠:LDP man-pages:3.76:2014/08/19:tzname:3:tzset:3:
-â\98\86:LDP man-pages:3.68=>3.76:2014/08/19:tzset:3:2014/06/08::amotoki@gmail.com:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/08/19:tzset:3:2015/01/07::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.76:2013/12/23:ualarm:3:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2014/05/28:ulckpwdf:3:getspnam:3:
○:LDP man-pages:3.76:2008/08/06:ulimit:3:2015/01/05::nakano@apm.seikei.ac.jp:NAKANO Takeo:
○:LDP man-pages:3.76:2013/09/04:wavelan:4:2015/01/05::ishikawa@linux.or.jp:ISHIKAWA Mutsumi:
＠:LDP man-pages:3.76:2009/02/23:zero:4:null:4:
○:LDP man-pages:3.76:2008/06/15:acct:5:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
-â\98\86:LDP man-pages:3.68=>3.76:2014/07/08:charmap:5:2014/06/08::argrath@ub32.org:Kentaro Shirakata:
+â\97\8b:LDP man-pages:3.76:2014/07/08:charmap:5:2015/01/07::argrath@ub32.org:Kentaro Shirakata:
○:LDP man-pages:3.76:2014/08/19:core:5:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.76:2013/08/09:dir_colors:5:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.76:2013/04/17:elf:5:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2014/12/31:procfs:5:proc:5:
○:LDP man-pages:3.76:2012/08/05:protocols:5:2015/01/05::argrath@ub32.org:Kentaro Shirakata:
×:LDP man-pages:3.76:2014/06/02:repertoiremap:5:::::
-â\98\86:LDP man-pages:3.68=>3.76:2014/12/31:resolv.conf:5:2014/06/08::amotoki@gmail.com:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/12/31:resolv.conf:5:2015/01/07::amotoki@gmail.com:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2014/12/31:resolver:5:resolv.conf:5:
○:LDP man-pages:3.76:1985/09/26:rpc:5:2015/01/05::argrath@ub32.org:Kentaro Shirakata:
○:LDP man-pages:3.76:1992/12/29:securetty:5:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
○:LDP man-pages:3.76:2014/10/02:ascii:7:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.76:2010/09/19:boot:7:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.76:2014/06/13:bootparam:7:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
-â\98\86:LDP man-pages:3.67=>3.76:2014/09/21:capabilities:7:2014/06/04::amotoki@gmail.com:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/09/21:capabilities:7:2015/01/07::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.76:2014/08/19:charsets:7:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.76:2011/09/16:complex:7:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
○:LDP man-pages:3.76:2014/12/31:cp1251:7:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.76:2014/12/31:credentials:7:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.76:2008/11/20:ddp:7:2015/01/05::nakano@apm.seikei.ac.jp:NAKANO Takeo:
○:LDP man-pages:3.76:2014/08/19:environ:7:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
-â\98\86:LDP man-pages:3.68=>3.76:2014/07/08:epoll:7:2014/06/08::amotoki@gmail.com:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/07/08:epoll:7:2015/01/07::amotoki@gmail.com:Akihiro MOTOKI:
×:LDP man-pages:3.76:2014/12/31:fanotify:7:::::
○:LDP man-pages:3.76:2014/03/20:feature_test_macros:7:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.76:2008/12/03:fifo:7:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
○:LDP man-pages:3.76:2012/08/05:hier:7:2015/01/05::nakano@apm.seikei.ac.jp:NAKANO Takeo:
○:LDP man-pages:3.76:2010/11/07:hostname:7:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.76:2012/05/10:icmp:7:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
-â\98\86:LDP man-pages:3.67=>3.76:2014/12/31:inotify:7:2014/06/04::amotoki@gmail.com:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/12/31:inotify:7:2015/01/07::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.76:2007/10/23:intro:7:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
-â\98\86:LDP man-pages:3.65=>3.76:2014/05/10:ip:7:2014/04/24::amotoki@gmail.com:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/05/10:ip:7:2015/01/07::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.76:2014/08/19:ipv6:7:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
＠:LDP man-pages:3.76:2014/10/02:iso-8859-1:7:iso_8859-1:7:
＠:LDP man-pages:3.76:2014/10/02:iso-8859-10:7:iso_8859-10:7:
○:LDP man-pages:3.76:2008/08/11:math_error:7:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
○:LDP man-pages:3.76:0000/00/00:mdoc:7:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.76:0000/00/00:mdoc.samples:7:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
-â\98\86:LDP man-pages:3.68=>3.76:2014/09/21:mq_overview:7:2014/06/08::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
-×:LDP man-pages:3.76:2014/09/21:namespaces:7:::::
+â\97\8b:LDP man-pages:3.76:2014/09/21:mq_overview:7:2015/01/07::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
+○:LDP man-pages:3.76:2014/09/21:namespaces:7:2015/01/07::amotoki@gmail.com:Akihiro Motoki:
○:LDP man-pages:3.76:2014/01/24:netdevice:7:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.76:2013/03/15:netlink:7:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.76:2012/08/05:numa:7:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.76:2011/09/09:operator:7:2015/01/05::ysato444@yahoo.co.jp:Yuichi SATO:
-â\98\86:LDP man-pages:3.65=>3.76:2014/08/19:packet:7:2014/04/27::amotoki@gmail.com:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/08/19:packet:7:2015/01/07::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.76:2009/12/05:path_resolution:7:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
×:LDP man-pages:3.76:2014/09/21:pid_namespaces:7:::::
○:LDP man-pages:3.76:2014/07/08:pipe:7:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
×:LDP man-pages:3.76:2007/12/20:spufs:7:::::
○:LDP man-pages:3.76:2014/01/15:standards:7:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
○:LDP man-pages:3.76:2000/11/16:suffixes:7:2015/01/05::ysato@h4.dion.ne.jp:Yuichi SATO:
-â\98\86:LDP man-pages:3.68=>3.76:2014/09/21:svipc:7:2014/06/08::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
+â\97\8b:LDP man-pages:3.76:2014/09/21:svipc:7:2015/01/07::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
×:LDP man-pages:3.76:2014/04/06:symlink:7:::::
○:LDP man-pages:3.76:2014/03/31:tcp:7:2015/01/05::amotoki@gmail.com:Akihiro MOTOKI:
○:LDP man-pages:3.76:2013/02/12:termio:7:2015/01/05::amotoki@dd.iij4u.or.jp:Akihiro MOTOKI:
OSDN Git Service
