.\" -*- coding: UTF-8 -*- '\" t .\" Copyright 1992, Drew Eckhardt .\" Copyright 2001-2019, Michael Kerrisk .\" Copyright, the authors of the Linux man-pages project .\" .\" SPDX-License-Identifier: GPL-1.0-or-later .\" .\"******************************************************************* .\" .\" This file was generated with po4a. Translate the source file. .\" .\"******************************************************************* .TH clone 2 "8 فبراير 2026" "صفحات دليل لينكس 6.18" .SH الاسم clone, __clone2, clone3 \- إنشاء عملية ابنة .SH المكتبة مكتبة سي المعيارية (\fIlibc\fP،\ \fI\-lc\fP) .SH موجز .nf /* النموذج المبدئي لدالة غلاف glibc */ .P \fB#define _GNU_SOURCE\fP \fB#include \fP .P \fBint clone(typeof(int (void *_Nullable)) *\fP\fIfn\fP\fB,\fP \fB void *\fP\fIstack\fP\fB,\fP \fB int \fP\fIflags\fP\fB,\fP \fB void *_Nullable \fP\fIarg\fP\fB, ...\fP \fB \fP\f[R]/*\fB pid_t *_Nullable \fP\fIparent_tid\fP\fB,\fP \fB void *_Nullable \fP\fItls\fP\fB,\fP \fB pid_t *_Nullable \fP\fIchild_tid\fP\fB \fP\f[R]*/\fB );\fP .P /* للنموذج المبدئي لنداء النظام الخام ()clone، انظر VERSIONS. */ .P \fB#include \fP /* تعريف \fBstruct clone_args\fP */ \fB#include \fP /* تعريف ثوابت \fBCLONE_*\fP */ \fB#include \fP /* تعريف ثوابت \fBSYS_*\fP */ \fB#include \fP .P \fBlong syscall(SYS_clone3, struct clone_args *\fP\fIcl_args\fP\fB, size_t \fP\fIsize\fP\fB);\fP .fi .P \fIملاحظة\fP: لا توفر glibc غلافًا لـ \fBclone3\fP()، مما يستلزم استخدام \fBsyscall\fP(2). .SH الوصف تنشئ نداءات النظام هذه عملية جديدة ("ابنة")، بطريقة مشابهة لـ \fBfork\fP(2). .P على النقيض من \fBfork\fP(2)، توفر نداءات النظام هذه تحكمًا أكثر دقة في أجزاء سياق التنفيذ التي تُتشارك بين المستدعِي والعملية الابنة. على سبيل المثال، باستخدام نداءات النظام هذه، يمكن لـ المستدعِي التحكم فيما إذا كانت العمليتان تتشاركان مساحة العناوين الافتراضية، وجدول واصفات الملفات، وجدول معالجات الإشارات أم لا. تسمح نداءات النظام هذه أيضًا بوضع العملية الابنة الجديدة في \fBnamespaces\fP(7) منفصلة. .P لاحظ أنه في صفحة الدليل هذه، تشير "المستدعِي" عادةً إلى "العملية الأب". ولكن انظر أوصاف \fBCLONE_PARENT\fP و \fBCLONE_THREAD\fP أدناه. .P تصف هذه الصفحة الواجهات التالية: .IP \[bu] 3 دالة غلاف glibc لـ \fBclone\fP() ونداء النظام الأساسي الذي تستند إليه. يصف النص الرئيس دالة الغلاف؛ وتوصَف الاختلافات في نداء النظام الخام قرب نهاية هذه الصفحة. .IP \[bu] نداء النظام \fBclone3\fP() الأحدث. .P .\" فيما تبقى من هذه الصفحة، يُستخدم المصطلح "نداء الاستنساخ" عند الإشارة إلى التفاصيل التي تنطبق على جميع هذه الواجهات. .SS "دالة الغلاف ()clone" عند إنشاء العملية الابنة باستخدام دالة غلاف \fBclone\fP()، فإنها تبدأ التنفيذ باستدعاء الدالة التي يشير إليها المعامل \fIfn\fP. (يختلف هذا عن \fBfork\fP(2)، حيث يستمر التنفيذ في الابن من نقطة استدعاء \fBfork\fP(2)). يُمرر المعامل \fIarg\fP كمعامل للدالة \fIfn\fP. .P عندما تعود الدالة \fIfn\fP(\fIarg\fP)، تنتهي العملية الابنة. الرقم الصحيح الذي تعيده \fIfn\fP هو حالة الخروج للعملية الابنة. قد تنتهي العملية الابنة أيضًا صراحةً باستدعاء \fBexit\fP(2) أو بعد تلقي إشارة قاتلة. .P يحدد المعامل \fIstack\fP موقع المكدس الذي تستخدمه العملية الابنة. وبما أن العملية الابنة والمستدعِي قد يتشاركان الذاكرة، فليس من الممكن للعملية الابنة أن تُنفذ في نفس المكدس الذي يستخدمه المستدعِي. يجب على المستدعِي بالتالي إعداد مساحة ذاكرة لمكدس الابن وتمرير مؤشر إلى هذه المساحة إلى \fBclone\fP(). تنمو المكدسات لأسفل في جميع المعالجات التي تشغل لينكس (باستثناء معالجات HP PA)، لذا يشير \fIstack\fP عادةً إلى أعلى عنوان في مساحة الذاكرة المعدة لمكدس الابن. لاحظ أن \fBclone\fP() لا توفر وسيلة يمكن من خلالها لـ المستدعِي إبلاغ النواة بحجم منطقة المكدس. .P .\" تُناقش المعاملات المتبقية لـ \fBclone\fP() أدناه. .SS clone3() يوفر نداء النظام \fBclone3\fP() مجموعة فائقة من وظائف واجهة \fBclone\fP() الأقدم. كما يوفر عددًا من تحسينات واجهة برمجة التطبيقات (API)، بما في ذلك: مساحة لبتات أعلام إضافية؛ وفصل أنظف في استخدام المعاملات المختلفة؛ والقدرة على تحديد حجم منطقة مكدس الابن. .P كما هو الحال مع \fBfork\fP(2)، يعود \fBclone3\fP() في كل من الأب والابن. ويعيد 0 في العملية الابنة ويعيد المعرف PID الخاص بالابن في الأب. .P المعامل \fIcl_args\fP لـ \fBclone3\fP() هو هيكل بالشكل التالي: .P .in +4n .EX struct clone_args { u64 flags; /* قناع بتات الأعلام */ u64 pidfd; /* مكان تخزين واصف ملف PID (\f[I]int *\fR) */ u64 child_tid; /* مكان تخزين معرف TID للابن، في ذاكرة الابن (\f[I]pid_t *\fR) */ u64 parent_tid; /* مكان تخزين معرف TID للابن، في ذاكرة الأب (\f[I]pid_t *\fR) */ u64 exit_signal; /* الإشارة التي تُرسل للأب عند إنهاء الابن */ u64 stack; /* مؤشر لأدنى بايت في المكدس */ u64 stack_size; /* حجم المكدس */ u64 tls; /* موقع TLS الجديد */ u64 set_tid; /* مؤشر لمصفوفة \f[I]pid_t\fR (منذ لينكس 5.5) */ u64 set_tid_size; /* عدد العناصر في \f[I]set_tid\fR (منذ لينكس 5.5) */ u64 cgroup; /* واصف ملف لمجموعة التحكم (cgroup) المستهدفة للابن (منذ لينكس 5.7) */ }; .EE .in .P يجب تهيئة المعامل \fIsize\fP الذي يُزود لـ \fBclone3\fP() ليساوي حجم هذا الهيكل. (وجود المعامل \fIsize\fP يسمح بتوسعات مستقبلية لهيكل \fIclone_args\fP). .P يُحدد مكدس العملية الابنة عبر \fIcl_args.stack\fP، الذي يشير إلى أدنى بايت في منطقة المكدس، و \fIcl_args.stack_size\fP، الذي يحدد حجم المكدس بالبايت. في الحالة التي يُحدد فيها علم \fBCLONE_VM\fP (انظر أدناه)، يجب تخصيص مكدس وتحديده صراحةً. خلاف ذلك، يمكن تحديد هذين الحقلين كـ NULL و 0، مما يجعل الابن يستخدم نفس منطقة مكدس الأب (في مساحة العناوين الافتراضية الخاصة بالابن). .P .\" تُناقش الحقول المتبقية في المعامل \fIcl_args\fP أدناه. .SS "التكافؤ بين معاملات ()clone و ()clone3" على عكس واجهة \fBclone\fP() الأقدم، حيث تُمرر المعاملات بشكل فردي، تُجمع المعاملات في واجهة \fBclone3\fP() الأحدث داخل هيكل \fIclone_args\fP الموضح أعلاه. يسمح هذا الهيكل بمجموعة فائقة من المعلومات الممرة عبر معاملات \fBclone\fP(). .P يوضح الجدول التالي التكافؤ بين معاملات \fBclone\fP() والحقول في المعامل \fIclone_args\fP المزود لـ \fBclone3\fP(): .RS 4 .TS lb lb lb l l l li li l. clone() clone3() ملاحظات حقل \f[I]cl_args\fR flags & \[ti]0xff flags T{ لمعظم الأعلام؛ التفاصيل أدناه T} parent_tid pidfd انظر CLONE_PIDFD child_tid child_tid انظر CLONE_CHILD_SETTID parent_tid parent_tid انظر CLONE_PARENT_SETTID flags & 0xff exit_signal stack stack \f[R]\-\-\-\fR stack_size tls tls انظر CLONE_SETTLS \f[R]\-\-\-\fR set_tid انظر أدناه للتفاصيل \f[R]\-\-\-\fR set_tid_size \f[R]\-\-\-\fR cgroup انظر CLONE_INTO_CGROUP .TE .RE .\" .SS "إشارة إنهاء الابن" .\" عند إنهاء العملية الابنة، قد تُرسل إشارة إلى الأب. تُحدد إشارة الإنهاء في البايت المنخفض لـ \fIflags\fP (\fBclone\fP()) أو في \fIcl_args.exit_signal\fP (\fBclone3\fP()). إذا حُددت هذه الإشارة كأي شيء آخر غير \fBSIGCHLD\fP، فيجب على العملية الأب تحديد الخيارات \fB__WALL\fP أو \fB__WCLONE\fP عند انتظار الابن باستخدام \fBwait\fP(2). إذا لم تُحدد أي إشارة (أي صفر)، فلن تُرسل إشارة إلى العملية الأب عند إنهاء الابن. .SS "مصفوفة set_tid" بشكل مبدئي، تختار النواة المعرف PID المتسلسل التالي للعملية الجديدة في كل من فضاءات أسماء PID التي توجد فيها. عند إنشاء عملية باستخدام \fBclone3\fP()، يمكن استخدام مصفوفة \fIset_tid\fP (المتوفرة منذ لينكس 5.5) لاختيار معرفات PID محددة للعملية في بعض أو كل فضاءات أسماء PID التي توجد فيها. إذا كان يجب ضبط PID للعملية المنشأة حديثًا فقط لفضاء أسماء PID الحالي أو في فضاء أسماء PID المنشأ حديثًا (إذا كانت \fIflags\fP تحتوي على \fBCLONE_NEWPID\fP) فيجب أن يكون العنصر الأول في مصفوفة \fIset_tid\fP هو الـ PID المطلوب ويجب أن يكون \fIset_tid_size\fP مساوياً لـ 1. .P إذا كان يجب أن يكون لـ PID العملية المنشأة حديثًا قيمة معينة في فضاءات أسماء PID متعددة، فيمكن أن تحتوي مصفوفة \fIset_tid\fP على مدخلات متعددة. يحدد المدخل الأول الـ PID في فضاء أسماء PID الأكثر تعشيشًا، ويحتوي كل من المدخلات التالية على الـ PID في فضاء أسماء PID السلف المقابل. يُحدد عدد فضاءات أسماء PID التي يجب ضبط الـ PID فيها بواسطة \fIset_tid_size\fP الذي لا يمكن أن يكون أكبر من عدد فضاءات أسماء PID المتداخلة حاليًا. .P لإنشاء عملية بمعرفات PID التالية في تسلسل هرمي لفضاء أسماء PID: .RS 4 .TS lb lb lb l l l. مستوى فضاء أسماء PID PID المطلوب ملاحظات 0 31496 فضاء أسماء PID الأبعد 1 42 2 7 فضاء أسماء PID الأكثر تعشيشًا .TE .RE .P اضبط المصفوفة على: .P .in +4n .EX set_tid[0] = 7; set_tid[1] = 42; set_tid[2] = 31496; set_tid_size = 3; .EE .in .P إذا كان يلزم فقط تحديد معرفات PID في فضاءي أسماء PID الأكثر تعشيشًا، فاضبط المصفوفة على: .P .in +4n .EX set_tid[0] = 7; set_tid[1] = 42; set_tid_size = 2; .EE .in .P يُختار الـ PID في فضاءات أسماء PID خارج الفضاءين الأكثر تعشيشًا بنفس الطريقة التي يُختار بها أي PID آخر. .P .\" commit 124ea650d3072b005457faed69909221c2905a1f .\" commit 1caef81da05a84a40dbf02110e967ce6d1135ff6 تتطلب ميزة \fIset_tid\fP صلاحية \fBCAP_SYS_ADMIN\fP أو (منذ لينكس 5.9) \fBCAP_CHECKPOINT_RESTORE\fP في جميع فضاءات أسماء المستخدمين المالكة لفضاءات أسماء PID المستهدفة. .P .\" يمكن لـ المستدعِين فقط اختيار PID أكبر من 1 في فضاء أسماء PID معين إذا كانت هناك عملية \fBinit\fP (أي عملية ذات PID 1) موجودة بالفعل في ذلك الفضاء. خلاف ذلك، يجب أن يكون مدخل الـ PID لفضاء أسماء PID هذا هو 1. .SS "قناع الأعلام" يسمح كل من \fBclone\fP() و \fBclone3\fP() باستخدام قناع بتات للأعلام يعدل سلوكهما ويسمح لـ المستدعِي بتحديد ما يُتشارك بين المستدعِي والعملية الابنة. يُشار إلى قناع البتات هذا — المعامل \fIflags\fP في \fBclone\fP() أو حقل \fIcl_args.flags\fP الممرر إلى \fBclone3\fP() — باسم قناع \fIflags\fP فيما تبقى من هذه الصفحة. .P يُحدد قناع \fIflags\fP كعملية OR بتية لصفر أو أكثر من الثوابت المدرجة أدناه. باستثناء ما هو مذكور أدناه، تتوفر هذه الأعلام (ولها نفس التأثير) في كل من \fBclone\fP() و \fBclone3\fP(). .TP \fBCLONE_CHILD_CLEARTID\fP (منذ لينكس 2.5.49) مسح (تصفير) معرف خيط الابن في الموقع الذي يشير إليه \fIchild_tid\fP (\fBclone\fP()) أو \fIcl_args.child_tid\fP (\fBclone3\fP()) في ذاكرة الابن عند خروجه، وإجراء تنبيه (wakeup) على futex في ذلك العنوان. يمكن تغيير العنوان المعني بواسطة نداء النظام \fBset_tid_address\fP(2). يُستخدم هذا بواسطة مكتبات الخيوط. .TP \fBCLONE_CHILD_SETTID\fP (منذ لينكس 2.5.49) تخزين معرف خيط الابن في الموقع الذي يشير إليه \fIchild_tid\fP (\fBclone\fP()) أو \fIcl_args.child_tid\fP (\fBclone3\fP()) في ذاكرة الابن. تكتمل عملية التخزين قبل أن يعيد نداء الاستنساخ التحكم إلى مساحة المستخدم في العملية الابنة. (لاحظ أن عملية التخزين قد لا تكون قد اكتملت قبل عودة نداء الاستنساخ في العملية الأب، وهو أمر ذو صلة إذا استُخدم علم \fBCLONE_VM\fP أيضًا). .TP \fBCLONE_CLEAR_SIGHAND\fP (منذ لينكس 5.5) .\" commit b612e5df4587c934bd056bf05f4a1deca4de4f75 بشكل مبدئي، تكون ترتيبات الإشارات في خيط الابن هي نفسها الموجودة في الأب. إذا حُدد هذا العلم، فإن جميع الإشارات التي تُعالج في الأب (ولم تُضبط على \fBSIG_IGN\fP) تُعاد إلى ترتيباتها المبدئية (\fBSIG_DFL\fP) في الابن. .IP تحديد هذا العلم مع \fBCLONE_SIGHAND\fP غير منطقي وغير مسموح به. .TP \fBCLONE_DETACHED\fP (تاريخي) .\" added in Linux 2.5.32; removed in Linux 2.6.0-test4 لفترة من الوقت (خلال سلسلة تطوير لينكس 2.5) كان هناك علم \fBCLONE_DETACHED\fP، والذي تسبب في عدم تلقي الأب إشارة عند إنهاء الابن. في النهاية، دُمج تأثير هذا العلم تحت علم \fBCLONE_THREAD\fP وبحلول وقت إصدار لينكس 2.6.0، لم يعد لهذا العلم أي تأثير. منذ لينكس 2.6.2، اختفت الحاجة لتقديم هذا العلم مع \fBCLONE_THREAD\fP. .IP لا يزال هذا العلم معرفًا، ولكن عادةً ما يُتجاهل عند استدعاء \fBclone\fP(). ومع ذلك، راجع وصف \fBCLONE_PIDFD\fP لمعرفة بعض الاستثناءات. .TP \fBCLONE_FILES\fP (منذ لينكس 2.0) إذا ضُبط \fBCLONE_FILES\fP، فإن العملية المستدعِية والعملية الوليدة تتشاركان نفس جدول واصفات الملفات. أي واصف ملف يُنشأ بواسطة العملية المستدعِية أو بواسطة العملية الوليدة يكون صالحًا أيضًا في العملية الأخرى. وبالمثل، إذا أغلقت إحدى العمليات واصف ملف، أو غيرت الأعلام المرتبطة به (باستخدام عملية \fBF_SETFD\fP في \fBfcntl\fP(2))، تتأثر العملية الأخرى أيضًا. إذا استدعت عملية تتشارك جدول واصفات ملفات \fBexecve\fP(2)، فإن جدول واصفات ملفاتها يُنسخ (يُفصل التشارك). .IP إذا لم يُضبط \fBCLONE_FILES\fP، ترث العملية الوليدة نسخة من جميع واصفات الملفات المفتوحة في العملية المستدعِية وقت استدعاء الاستنساخ. العمليات اللاحقة التي تفتح أو تغلق واصفات الملفات، أو تغير أعلام واصف الملف، والتي تقوم بها إما العملية المستدعِية أو العملية الوليدة لا تؤثر على العملية الأخرى. لاحظ، مع ذلك، أن واصفات الملفات المنسوخة في الوليدة تشير إلى نفس أوصاف الملفات المفتوحة مثل واصفات الملفات المقابلة في العملية المستدعِية، وبالتالي تتشارك إزاحات الملف وأعلام حالة الملف (انظر \fBopen\fP(2)). .TP \fBCLONE_FS\fP (منذ لينكس 2.0) إذا ضُبط \fBCLONE_FS\fP، يتشارك المستدعِي والعملية الوليدة نفس معلومات نظام الملفات. يتضمن ذلك جذر نظام الملفات، ودليل العمل الحالي، وقناع وضع إنشاء الملفات (umask). أي استدعاء لـ \fBchroot\fP(2) أو \fBchdir\fP(2) أو \fBumask\fP(2) تقوم به العملية المستدعِية أو العملية الوليدة يؤثر أيضًا على العملية الأخرى. .IP إذا لم يُضبط \fBCLONE_FS\fP، تعمل العملية الوليدة على نسخة من معلومات نظام الملفات للعملية المستدعِية وقت استدعاء الاستنساخ. الاستدعاءات لـ \fBchroot\fP(2) أو \fBchdir\fP(2) أو \fBumask\fP(2) التي تُجرى لاحقًا بواسطة إحدى العمليات لا تؤثر على العملية الأخرى. .TP \fBCLONE_INTO_CGROUP\fP (منذ لينكس 5.7) .\" commit ef2c41cf38a7559bbf91af42d5b6a4429db8fc68 بشكل مبدئي، توضع العملية الوليدة في نفس مجموعة التحكم (cgroup) الإصدار 2 التي تتبعها العملية الأب. يسمح علم \fBCLONE_INTO_CGROUP\fP بإنشاء العملية الوليدة في مجموعة تحكم إصدار 2 مختلفة. (لاحظ أن \fBCLONE_INTO_CGROUP\fP له تأثير فقط على مجموعات التحكم من الإصدار 2.) .IP لوضع العملية الوليدة في مجموعة تحكم مختلفة، يحدد المستدعِي \fBCLONE_INTO_CGROUP\fP في \fIcl_args.flags\fP ويمرر واصف ملف يشير إلى مجموعة تحكم إصدار 2 في حقل \fIcl_args.cgroup\fP. (يمكن الحصول على واصف الملف هذا عن طريق فتح دليل cgroup v2 باستخدام إما علم \fBO_RDONLY\fP أو علم \fBO_PATH\fP.) لاحظ أن جميع القيود المعتادة (الموضحة في \fBcgroups\fP(7)) بشأن وضع عملية في مجموعة تحكم إصدار 2 تنطبق هنا. .IP من بين حالات الاستخدام الممكنة لـ \fBCLONE_INTO_CGROUP\fP ما يلي: .RS .IP \[bu] 3 إن تفريخ عملية في مجموعة تحكم مختلفة عن مجموعة تحكم الأب يجعل من الممكن لمدير الخدمات تفريخ خدمات جديدة مباشرة في مجموعات تحكم مخصصة. هذا يزيل اضطراب المحاسبة الذي قد يحدث إذا أُنشئت العملية الوليدة أولاً في نفس مجموعة تحكم الأب ثم نُقلت إلى مجموعة التحكم المستهدفة. علاوة على ذلك، فإن تفريخ العملية الوليدة مباشرة في مجموعة تحكم مستهدفة أقل تكلفة بكثير من نقل العملية الوليدة إلى مجموعة التحكم المستهدفة بعد إنشائها. .IP \[bu] يسمح علم \fBCLONE_INTO_CGROUP\fP أيضًا بإنشاء عمليات وليدة مجمدة عن طريق تفريخها في مجموعة تحكم مجمدة. (انظر \fBcgroups\fP(7) للحصول على وصف لمتحكم التجميد.) .IP \[bu] بالنسبة للتطبيقات متعددة الخيوط (أو حتى تنفيذات الخيوط التي تستخدم مجموعات التحكم للحد من الخيوط الفردية)، من الممكن إنشاء تخطيط ثابت لمجموعة التحكم قبل تفريخ كل خيط مباشرة في مجموعة التحكم المستهدفة الخاصة به. .RE .TP \fBCLONE_IO\fP (منذ لينكس 2.6.25) إذا ضُبط \fBCLONE_IO\fP، فإن العملية الجديدة تتشارك سياق إدخال/إخراج مع العملية المستدعِية. إذا لم يُضبط هذا العلم، فإن العملية الجديدة (كما في \fBfork\fP(2)) يكون لها سياق إدخال/إخراج خاص بها. .IP .\" The following based on text from Jens Axboe .\" the anticipatory and CFQ scheduler .\" with CFQ and AS. سياق الإدخال/الإخراج هو نطاق الإدخال/الإخراج لجدول القرص (أي ما يستخدمه مجدول الإدخال/الإخراج لنمذجة جدولة إدخال/إخراج العملية). إذا تشاركت العمليات نفس سياق الإدخال/الإخراج، فإن مجدول الإدخال/الإخراج يعاملها كعملية واحدة. نتيجة لذلك، فإنها تتشارك وقت القرص. بالنسبة لبعض مجدولي الإدخال/الإخراج، إذا تشاركت عمليتان في سياق إدخال/إخراج واحد، فسيُسمح لهما بتداخل وصولهما إلى القرص. إذا كانت عدة خيوط تقوم بالإدخال/الإخراج نيابة عن نفس العملية (\fBaio_read\fP(3)، على سبيل المثال)، فيجب عليها استخدام \fBCLONE_IO\fP للحصول على أداء إدخال/إخراج أفضل. .IP إذا لم تُضبط النواة بخيار \fBCONFIG_BLOCK\fP، فإن هذا العلم لا يفعل شيئًا. .TP \fBCLONE_NEWCGROUP\fP (منذ لينكس 4.6) إنشاء العملية في فضاء أسماء cgroup جديد. إذا لم يُضبط هذا العلم، فإن العملية (كما في \fBfork\fP(2)) تُنشأ في نفس فضاءات أسماء cgroup الخاصة بالعملية المستدعِية. .IP لمزيد من المعلومات حول فضاءات أسماء cgroup، راجع \fBcgroup_namespaces\fP(7). .IP .\" فقط العملية ذات الامتيازات (\fBCAP_SYS_ADMIN\fP) يمكنها استخدام \fBCLONE_NEWCGROUP\fP. .TP \fBCLONE_NEWIPC\fP (منذ لينكس 2.6.19) إذا ضُبط \fBCLONE_NEWIPC\fP، فسيتم إنشاء العملية في فضاء أسماء IPC جديد. إذا لم يُضبط هذا العلم، فإن العملية (كما في \fBfork\fP(2)) تُنشأ في نفس فضاء أسماء IPC الخاص بالعملية المستدعِية. .IP لمزيد من المعلومات حول فضاءات أسماء IPC، راجع \fBipc_namespaces\fP(7). .IP فقط العملية ذات الامتيازات (\fBCAP_SYS_ADMIN\fP) يمكنها استخدام \fBCLONE_NEWIPC\fP. لا يمكن تحديد هذا العلم بالتزامن مع \fBCLONE_SYSVSEM\fP. .TP \fBCLONE_NEWNET\fP (منذ لينكس 2.6.24) (اكتمل تنفيذ هذا العلم فقط في حوالي لينكس 2.6.29.) .IP إذا ضُبط \fBCLONE_NEWNET\fP، فسيتم إنشاء العملية في فضاء أسماء شبكة جديد. إذا لم يُضبط هذا العلم، فإن العملية (كما في \fBfork\fP(2)) تُنشأ في نفس فضاء أسماء الشبكة الخاص بالعملية المستدعِية. .IP لمزيد من المعلومات حول فضاءات أسماء الشبكة، راجع \fBnetwork_namespaces\fP(7). .IP فقط العملية ذات الامتيازات (\fBCAP_SYS_ADMIN\fP) يمكنها استخدام \fBCLONE_NEWNET\fP. .TP \fBCLONE_NEWNS\fP (منذ لينكس 2.4.19) إذا ضُبط \fBCLONE_NEWNS\fP، تبدأ الوليدة المستنسخة في فضاء أسماء وصل جديد، يُهيأ بنسخة من فضاء أسماء الأب. إذا لم يُضبط \fBCLONE_NEWNS\fP، تعيش الوليدة في نفس فضاء أسماء الوصل الخاص بالأب. .IP لمزيد من المعلومات حول فضاءات أسماء الوصل، راجع \fBnamespaces\fP(7) و \fBmount_namespaces\fP(7). .IP .\" See https://lwn.net/Articles/543273/ فقط العملية ذات الامتيازات (\fBCAP_SYS_ADMIN\fP) يمكنها استخدام \fBCLONE_NEWNS\fP. لا يُسمح بتحديد كل من \fBCLONE_NEWNS\fP و \fBCLONE_FS\fP في نفس استدعاء الاستنساخ. .TP \fBCLONE_NEWPID\fP (منذ لينكس 2.6.24) .\" This explanation draws a lot of details from .\" http://lwn.net/Articles/259217/ .\" Authors: Pavel Emelyanov .\" and Kir Kolyshkin .\" .\" The primary kernel commit is 30e49c263e36341b60b735cbef5ca37912549264 .\" Author: Pavel Emelyanov إذا ضُبط \fBCLONE_NEWPID\fP، فسيتم إنشاء العملية في فضاء أسماء PID جديد. إذا لم يُضبط هذا العلم، فإن العملية (كما في \fBfork\fP(2)) تُنشأ في نفس فضاء أسماء PID الخاص بالعملية المستدعِية. .IP لمزيد من المعلومات حول فضاءات أسماء PID، راجع \fBnamespaces\fP(7) و \fBpid_namespaces\fP(7). .IP فقط العملية ذات الامتيازات (\fBCAP_SYS_ADMIN\fP) يمكنها استخدام \fBCLONE_NEWPID\fP. لا يمكن تحديد هذا العلم بالتزامن مع \fBCLONE_THREAD\fP. .TP \fBCLONE_NEWUSER\fP (أصبح هذا العلم ذا معنى لأول مرة لـ \fBclone\fP() في لينكس 2.6.23، ودُمجت دلالات \fBclone\fP() الحالية في لينكس 3.5، ودُمجت الأجزاء النهائية لجعل فضاءات أسماء المستخدمين قابلة للاستخدام بالكامل في لينكس 3.8.) .IP إذا ضُبط \fBCLONE_NEWUSER\fP، فسيتم إنشاء العملية في فضاء أسماء مستخدم جديد. إذا لم يُضبط هذا العلم، فإن العملية (كما في \fBfork\fP(2)) تُنشأ في نفس فضاء أسماء المستخدمين الخاص بالعملية المستدعِية. .IP لمزيد من المعلومات حول فضاءات أسماء المستخدمين، راجع \fBnamespaces\fP(7) و \fBuser_namespaces\fP(7). .IP .\" Before Linux 2.6.29, it appears that only CAP_SYS_ADMIN was needed قبل لينكس 3.8، كان استخدام \fBCLONE_NEWUSER\fP يتطلب أن يكون لدى المستدعِي ثلاث قدرات: \fBCAP_SYS_ADMIN\fP و \fBCAP_SETUID\fP و \fBCAP_SETGID\fP. بدءًا من لينكس 3.8، لا حاجة لامتيازات لإنشاء فضاء أسماء مستخدم. .IP .\" commit e66eded8309ebf679d3d3c1f5820d1f2ca332c71 .\" https://lwn.net/Articles/543273/ .\" The fix actually went into Linux 3.9 and into Linux 3.8.3. .\" However, user namespaces were, for practical purposes, .\" unusable in earlier Linux 3.8.x because of the various filesystems .\" that didn't support userns. لا يمكن تحديد هذا العلم بالتزامن مع \fBCLONE_THREAD\fP أو \fBCLONE_PARENT\fP. لأسباب أمنية، لا يمكن تحديد \fBCLONE_NEWUSER\fP بالتزامن مع \fBCLONE_FS\fP. .TP \fBCLONE_NEWUTS\fP (منذ لينكس 2.6.19) إذا ضُبط \fBCLONE_NEWUTS\fP، فسيتم إنشاء العملية في فضاء أسماء UTS جديد، وتُهيأ معرفاته بنسخ المعرفات من فضاء أسماء UTS للعملية المستدعِية. إذا لم يُضبط هذا العلم، فإن العملية (كما في \fBfork\fP(2)) تُنشأ في نفس فضاء أسماء UTS الخاص بالعملية المستدعِية. .IP لمزيد من المعلومات حول فضاءات أسماء UTS، راجع \fButs_namespaces\fP(7). .IP فقط العملية ذات الامتيازات (\fBCAP_SYS_ADMIN\fP) يمكنها استخدام \fBCLONE_NEWUTS\fP. .TP \fBCLONE_PARENT\fP (منذ لينكس 2.3.12) إذا ضُبط \fBCLONE_PARENT\fP، فإن أب الوليدة الجديدة (كما تعيده \fBgetppid\fP(2)) سيكون هو نفسه أب العملية المستدعِية. .IP إذا لم يُضبط \fBCLONE_PARENT\fP، فإن أب الوليدة (كما في \fBfork\fP(2)) هو العملية المستدعِية. .IP لاحظ أن العملية الأب، كما تعيدها \fBgetppid\fP(2)، هي التي تتلقى إشارة عند إنهاء الوليدة، بحيث إذا ضُبط \fBCLONE_PARENT\fP، فإن أب العملية المستدعِية، وليس العملية المستدعِية نفسها، هو من يتلقى الإشارة. .IP لا يمكن استخدام علم \fBCLONE_PARENT\fP في استدعاءات الاستنساخ من قبل عملية البدء العامة (PID 1 في فضاء أسماء PID الأولي) وعمليات البدء في فضاءات أسماء PID الأخرى. يمنع هذا القيد إنشاء أشجار عمليات متعددة الجذور بالإضافة إلى منع إنشاء زومبي لا يمكن حصادهم في فضاء أسماء PID الأولي. .TP \fBCLONE_PARENT_SETTID\fP (منذ لينكس 2.5.49) تخزين معرف خيط الوليدة في الموقع الذي يشير إليه \fIparent_tid\fP (في \fBclone\fP()) أو \fIcl_args.parent_tid\fP (في \fBclone3\fP()) في ذاكرة الأب. (في لينكس 2.5.32\-2.5.48 كان هناك علم \fBCLONE_SETTID\fP يقوم بذلك.) تكتمل عملية التخزين قبل أن يعيد استدعاء الاستنساخ التحكم إلى مساحة المستخدم. .TP \fBCLONE_PID\fP (لينكس 2.0 إلى لينكس 2.5.15) إذا ضُبط \fBCLONE_PID\fP، تُنشأ العملية الوليدة بنفس معرف العملية للمستدعِية. هذا مفيد لاختراق النظام، ولكنه غير مفيد لغير ذلك. من لينكس 2.3.21 فصاعدًا، أصبح بالإمكان تحديد هذا العلم فقط بواسطة عملية تمهيد النظام (PID 0). اختفى العلم تمامًا من مصادر النواة في لينكس 2.5.16. لاحقًا، تجاهلت النواة بصمت هذه البتة إذا حُددت في قناع \fIالأعلام\fP. وبعد فترة طويلة، أُعيد تدوير نفس البتة لاستخدامها كعلم \fBCLONE_PIDFD\fP. .TP \fBCLONE_PIDFD\fP (منذ لينكس 5.2) .\" commit b3e5838252665ee4cfa76b82bdf1198dca81e5be إذا حُدد هذا العلم، يُخصص واصف ملف PID يشير إلى العملية الوليدة ويُوضع في موقع محدد في ذاكرة الأب. يُضبط علم الإغلاق عند التنفيذ (close\-on\-exec) على واصف الملف الجديد هذا. يمكن استخدام واصفات ملفات PID للأغراض الموضحة في \fBpidfd_open\fP(2). .RS .IP \[bu] 3 عند استخدام \fBclone3\fP()، يُوضع واصف ملف PID في الموقع الذي يشير إليه \fIcl_args.pidfd\fP. .IP \[bu] عند استخدام \fBclone\fP()، يُوضع واصف ملف PID في الموقع الذي يشير إليه \fIparent_tid\fP. وبما أن معامل \fIparent_tid\fP يُستخدم لإعادة واصف ملف PID، فلا يمكن استخدام \fBCLONE_PIDFD\fP مع \fBCLONE_PARENT_SETTID\fP عند استدعاء \fBclone\fP(). .RE .IP .\" commit 83b290c9e3b5d95891f43a4aeadf6071cbff25d3 إذا حُدد \fBCLONE_PIDFD\fP مع \fBCLONE_THREAD\fP، فإن واصف ملف PID الذي تم الحصول عليه يشير إلى خيط معين، بدلاً من متصدر مجموعة الخيوط إذا لم يُحدد \fBCLONE_THREAD\fP. تتوفر هذه الميزة منذ لينكس 6.9. .IP إذا حُدد علم \fBCLONE_DETACHED\fP المهمل بجانب \fBCLONE_PIDFD\fP عند استدعاء \fBclone\fP()، فسيُعاد خطأ. وينتج خطأ أيضًا إذا حُدد \fBCLONE_DETACHED\fP عند استدعاء \fBclone3\fP(). يضمن سلوك الخطأ هذا إمكانية إعادة استخدام البتة المقابلة لـ \fBCLONE_DETACHED\fP لميزات واصف ملف PID الإضافية في المستقبل. .TP \fBCLONE_PTRACE\fP (منذ لينكس 2.2) إذا حُدد \fBCLONE_PTRACE\fP، وكانت العملية المستدعِية تخضع للتتبع، فسيتم تتبع الوليدة أيضًا (راجع \fBptrace\fP(2)). .TP \fBCLONE_SETTLS\fP (منذ لينكس 2.5.32) يُضبط واصف TLS (تخزين الخيط المحلي) على \fItls\fP. .IP تفسير \fItls\fP والأثر الناتج يعتمد على المعمارية. في x86، يُفسر \fItls\fP على أنه \fIstruct user_desc\ *\fP (راجع \fBset_thread_area\fP(2)). في x86\-64 هي القيمة الجديدة التي ستُضبط لسجل القاعدة %fs (راجع معامل \fBARCH_SET_FS\fP لـ \fBarch_prctl\fP(2)). في المعماريات التي تحتوي على سجل TLS مخصص، فهي القيمة الجديدة لذلك السجل. .IP يتطلب استخدام هذا العلم معرفة مفصلة وعمومًا لا ينبغي استخدامه إلا في المكتبات التي تنفذ تعدد الخيوط. .TP \fBCLONE_SIGHAND\fP (منذ لينكس 2.0) إذا ضُبط \fBCLONE_SIGHAND\fP، تتشارك العملية المستدعِية والوليدة في نفس جدول معالجي الإشارات. إذا استدعت العملية المستدعِية أو الوليدة \fBsigaction\fP(2) لتغيير السلوك المرتبط بإشارة ما، يتغير السلوك في العملية الأخرى أيضًا. ومع ذلك، لا يزال للعملية المستدعِية والوليدة أقنعة إشارات ومجموعات إشارات معلقة متميزة. لذا، يمكن لإحداهما حجب أو إلغاء حجب الإشارات باستخدام \fBsigprocmask\fP(2) دون التأثير على العملية الأخرى. .IP إذا لم يُضبط \fBCLONE_SIGHAND\fP، ترث العملية الوليدة نسخة من معالجي الإشارات للعملية المستدعِية وقت استدعاء الاستنساخ. الاستدعاءات لـ \fBsigaction\fP(2) التي تُجرى لاحقًا بواسطة إحدى العمليات ليس لها أي تأثير على العملية الأخرى. .IP .\" Precisely: Linux 2.6.0-test6 منذ لينكس 2.6.0، يجب أن يتضمن قناع \fIflags\fP أيضًا \fBCLONE_VM\fP إذا حُدد \fBCLONE_SIGHAND\fP. .TP \fBCLONE_STOPPED\fP (منذ لينكس 2.6.0) .\" Precisely: Linux 2.6.0-test2 إذا ضُبط \fBCLONE_STOPPED\fP، فسيتم إيقاف الوليدة في البداية (كما لو أُرسلت إليها إشارة \fBSIGSTOP\fP)، ويجب استئنافها عن طريق إرسال إشارة \fBSIGCONT\fP إليها. .IP .\" glibc 2.8 removed this defn from bits/sched.h \fIأُهمل\fP هذا العلم منذ لينكس 2.6.25 فصاعدًا، و\fIأُزيل\fP تمامًا في لينكس 2.6.38. ومنذ ذلك الحين، تتجاهله النواة بصمت دون خطأ. بدءًا من لينكس 4.6، أُعيد تدوير نفس البتة لعلم \fBCLONE_NEWCGROUP\fP. .TP \fBCLONE_SYSVSEM\fP (منذ لينكس 2.5.10) إذا ضُبط \fBCLONE_SYSVSEM\fP، تتشارك الوليدة والعملية المستدعِية في قائمة واحدة لقيم تعديل سيمافور System V (تُعرف بـ \fIsemadj\fP) (راجع \fBsemop\fP(2)). في هذه الحالة، تراكم القائمة المشتركة قيم \fIsemadj\fP عبر جميع العمليات التي تتشارك القائمة، وتُجرى تعديلات السيمافور فقط عندما تنتهي آخر عملية تشارك القائمة (أو تتوقف عن مشاركتها باستخدام \fBunshare\fP(2)). إذا لم يُضبط هذا العلم، يكون للوليدة قائمة \fIsemadj\fP منفصلة تكون فارغة في البداية. .TP \fBCLONE_THREAD\fP (منذ لينكس 2.4.0) .\" Precisely: Linux 2.6.0-test8 إذا ضُبط \fBCLONE_THREAD\fP، تُوضع الوليدة في نفس مجموعة الخيوط التي تتبعها العملية المستدعِية. ولجعل ما تبقى من مناقشة \fBCLONE_THREAD\fP أكثر قابلية للقراءة، استُخدم مصطلح "خيط" للإشارة إلى العمليات داخل مجموعة الخيوط. .IP كانت مجموعات الخيوط ميزة أضيفت في لينكس 2.4 لدعم مفهوم خيوط POSIX لمجموعة من الخيوط التي تتشارك معرف عملية (PID) واحد. داخليًا، هذا المعرف المشترك هو ما يسمى بمعرف مجموعة الخيوط (TGID). منذ لينكس 2.4، تعيد الاستدعاءات لـ \fBgetpid\fP(2) معرف TGID للمستدعِي. .IP يمكن تمييز الخيوط داخل المجموعة من خلال معرفات الخيوط (TID) الفريدة (على مستوى النظام). يتوفر معرف TID للخيط الجديد كنتيجة دالة تعاد للمستدعِي، ويمكن للخيط الحصول على معرف TID الخاص به باستخدام \fBgettid\fP(2). .IP عند إجراء استدعاء استنساخ بدون تحديد \fBCLONE_THREAD\fP، يُوضع الخيط الناتج في مجموعة خيوط جديدة يكون معرف TGID الخاص بها هو نفسه معرف TID للخيط. هذا الخيط هو \fIمتصدر\fP مجموعة الخيوط الجديدة. .IP الخيط الجديد المنشأ باستخدام \fBCLONE_THREAD\fP له نفس العملية الأب للعملية التي أجرت استدعاء الاستنساخ (أي، مثل \fBCLONE_PARENT\fP)، بحيث تعيد الاستدعاءات لـ \fBgetppid\fP(2) نفس القيمة لجميع الخيوط في مجموعة خيوط واحدة. عندما ينتهي خيط \fBCLONE_THREAD\fP، لا تُرسل للخيط الذي أنشأه إشارة \fBSIGCHLD\fP (أو أي إشارة إنهاء أخرى)؛ ولا يمكن الحصول على حالة مثل هذا الخيط باستخدام \fBwait\fP(2). (يُقال عن الخيط إنه \fIمنفصل\fP). .IP بعد انتهاء جميع الخيوط في مجموعة الخيوط، تُرسل للعملية الأب لمجموعة الخيوط إشارة \fBSIGCHLD\fP (أو إشارة إنهاء أخرى). .IP إذا قام أي من الخيوط في مجموعة خيوط بتنفيذ \fBexecve\fP(2)، فسيتم إنهاء جميع الخيوط الأخرى باستثناء متصدر مجموعة الخيوط، ويُنفذ البرنامج الجديد في متصدر مجموعة الخيوط. .IP إذا أنشأ أحد الخيوط في مجموعة خيوط وليدة باستخدام \fBfork\fP(2)، فيمكن لأي خيط في المجموعة انتظار (\fBwait\fP(2)) تلك الوليدة. .IP .\" Precisely: Linux 2.6.0-test6 منذ لينكس 2.5.35، يجب أن يتضمن قناع \fIflags\fP أيضًا \fBCLONE_SIGHAND\fP إذا حُدد \fBCLONE_THREAD\fP (ولاحظ أنه منذ لينكس 2.6.0، يتطلب \fBCLONE_SIGHAND\fP أيضًا تضمين \fBCLONE_VM\fP). .IP ترتيبات الإشارات وإجراءاتها تكون على مستوى العملية: إذا سُلّمت إشارة غير معالجة إلى خيط ما، فإنها ستؤثر على (تنهي، توقف، تواصل، تُتجاهل في) جميع أعضاء مجموعة الخيوط. .IP لكل خيط قناع إشارات خاص به، كما يُضبط بواسطة \fBsigprocmask\fP(2). .IP قد تكون الإشارة موجهة للعملية أو موجهة للخيط. تستهدف الإشارة الموجهة للعملية مجموعة خيوط (أي معرف TGID)، وتُسلّم إلى خيط مختار عشوائيًا من بين تلك التي لا تحجب الإشارة. قد تكون الإشارة موجهة للعملية لأنها نُتجت بواسطة النواة لأسباب أخرى غير استثناء الأجهزة، أو لأنها أُرسلت باستخدام \fBkill\fP(2) أو \fBsigqueue\fP(3). تستهدف الإشارة الموجهة للخيط (أي تُسلّم إلى) خيطًا معينًا. قد تكون الإشارة موجهة للخيط لأنها أُرسلت باستخدام \fBtgkill\fP(2) أو \fBpthread_sigqueue\fP(3)، أو لأن الخيط نفذ تعليمة بلغة الآلة أدت إلى إطلاق استثناء في الأجهزة (على سبيل المثال، وصول غير صالح للذاكرة أطلق \fBSIGSEGV\fP أو استثناء نقطة عائمة أطلق \fBSIGFPE\fP). .IP يعيد استدعاء \fBsigpending\fP(2) مجموعة إشارات تمثل اتحاد الإشارات المعلقة الموجهة للعملية والإشارات المعلقة للخيط المستدعِي. .IP إذا سُلّمت إشارة موجهة للعملية إلى مجموعة خيوط، وقامت مجموعة الخيوط بتثبيت معالج للإشارة، فسيتم استدعاء المعالج في عضو واحد بالضبط، يُختار عشوائيًا من أعضاء مجموعة الخيوط الذين لم يحجبوا الإشارة. إذا كانت خيوط متعددة في مجموعة ما تنتظر قبول نفس الإشارة باستخدام \fBsigwaitinfo\fP(2)، فستختار النواة عشوائيًا أحد هذه الخيوط لتلقي الإشارة. .TP \fBCLONE_UNTRACED\fP (منذ لينكس 2.5.46) إذا حُدد \fBCLONE_UNTRACED\fP، فلا يمكن لعملية التتبع فرض \fBCLONE_PTRACE\fP على هذه العملية الوليدة. .TP \fBCLONE_VFORK\fP (منذ لينكس 2.2) إذا ضُبط \fBCLONE_VFORK\fP، يُعلق تنفيذ العملية المستدعِية حتى تحرر الوليدة موارد ذاكرتها الافتراضية عبر استدعاء \fBexecve\fP(2) أو \fB_exit\fP(2) (كما هو الحال مع \fBvfork\fP(2)). .IP إذا لم يُضبط \fBCLONE_VFORK\fP، فستكون كل من العملية المستدعِية والوليدة قابلتين للجدولة بعد الاستدعاء، ولا ينبغي للتطبيق الاعتماد على حدوث التنفيذ بأي ترتيب معين. .TP \fBCLONE_VM\fP (منذ لينكس 2.0) إذا ضُبطت \fBCLONE_VM\fP، فستعمل العملية المستدعية والعملية الوليدة في مساحة الذاكرة ذاتها. وعلى وجه الخصوص، تكون عمليات كتابة الذاكرة التي تجريها العملية المستدعية أو العملية الوليدة مرئية أيضًا في العملية الأخرى. علاوة على ذلك، فإن أي وصل أو فصل لذاكرة يُجرى باستخدام \fBmmap\fP(2) أو \fBmunmap\fP(2) بواسطة العملية الوليدة أو المستدعية يؤثر أيضًا في العملية الأخرى. .IP إذا لم تُضبط \fBCLONE_VM\fP، فستعمل العملية الوليدة في نسخة منفصلة من مساحة ذاكرة العملية المستدعية وقت استدعاء الاستنساخ. ولا تؤثر عمليات كتابة الذاكرة أو وصل/فصل الملفات التي تجريها إحدى العمليتين في الأخرى، تمامًا كما في \fBfork\fP(2). .IP إذا حُددت علامة \fBCLONE_VM\fP ولم تُحدد علامة \fBCLONE_VFORK\fP، فسيُمسح أي كدس إشارات بديل أُنشئ بواسطة \fBsigaltstack\fP(2) في العملية الوليدة. .SH "قيمة الإرجاع" .\" gettid(2) returns current->pid; .\" getpid(2) returns current->tgid; عند النجاح، يُعاد معرف الخيط (thread ID) للعملية الوليدة في خيط التنفيذ الخاص بالمستدعِي. وفي حالة الفشل، يُعاد \-1 في سياق المستدعِي، ولا تُنشأ أي عملية وليدة، وتُضبط \fIerrno\fP للإشارة إلى الخطأ. .SH الأخطاء .TP \fBE2BIG\fP (في \fBclone3\fP() فقط) النواة لا تدعم بعض الوظائف المطلوبة في استدعاء \fBclone3\fP() هذا: معطى الحجم أكبر مما تدعمه النواة، وتوجد قيم غير صفرية في البنية (struct) بعد الحجم الذي تدعمه النواة. .TP \fBE2BIG\fP (في \fBclone3\fP() فقط) معطى الحجم أكبر من حجم الصفحة. .TP \fBEACCES\fP (في \fBclone3\fP() فقط) حُددت \fBCLONE_INTO_CGROUP\fP في \fIcl_args.flags\fP، ولكن القيود (الموضحة في \fBcgroups\fP(7)) المفروضة على وضع العملية الوليدة في الإصدار 2 من مجموعات التحكم (cgroup) المشار إليها بواسطة \fIcl_args.cgroup\fP لم تُستوفَ. .TP \fBEAGAIN\fP هناك عدد كبير جدًا من العمليات قيد التشغيل بالفعل؛ انظر \fBfork\fP(2). .TP \fBEBUSY\fP (في \fBclone3\fP() فقط) حُددت \fBCLONE_INTO_CGROUP\fP في \fIcl_args.flags\fP، لكن واصف الملف المحدد في \fIcl_args.cgroup\fP يشير إلى مجموعة تحكم (cgroup) من الإصدار 2 تملك متحكم نطاق (domain controller) مُفعّلًا. .TP \fBEEXIST\fP (في \fBclone3\fP() فقط) واحد (أو أكثر) من معرفات العمليات (PIDs) المحددة في \fIset_tid\fP موجود بالفعل في مساحة أسماء PID المقابلة. .TP \fBEINVAL\fP كلا \fBCLONE_SIGHAND\fP و \fBCLONE_CLEAR_SIGHAND\fP حُددا في قناع \fIflags\fP. .TP \fBEINVAL\fP .\" Precisely: Linux 2.6.0-test6 حُددت \fBCLONE_SIGHAND\fP في قناع \fIflags\fP، لكن \fBCLONE_VM\fP لم تُحدد. (منذ لينكس 2.6.0.) .TP \fBEINVAL\fP .\" .TP .\" .B EINVAL .\" Precisely one of .\" .B CLONE_DETACHED .\" and .\" .B CLONE_THREAD .\" was specified. .\" (Since Linux 2.6.0-test6.) حُددت \fBCLONE_THREAD\fP في قناع \fIflags\fP، لكن \fBCLONE_SIGHAND\fP لم تُحدد. (منذ لينكس 2.5.35.) .TP \fBEINVAL\fP حُددت \fBCLONE_THREAD\fP في قناع \fIflags\fP، لكن العملية الحالية استدعت سابقًا \fBunshare\fP(2) مع علامة \fBCLONE_NEWPID\fP أو استخدمت \fBsetns\fP(2) لإعادة ربط نفسها بمساحة أسماء PID. .TP \fBEINVAL\fP .\" commit e66eded8309ebf679d3d3c1f5820d1f2ca332c71 كلا \fBCLONE_FS\fP و \fBCLONE_NEWNS\fP حُددا في قناع \fIflags\fP. .TP \fBEINVAL\fP (منذ لينكس 3.9) كلا \fBCLONE_NEWUSER\fP و \fBCLONE_FS\fP حُددا في قناع \fIflags\fP. .TP \fBEINVAL\fP كلا \fBCLONE_NEWIPC\fP و \fBCLONE_SYSVSEM\fP حُددا في قناع \fIflags\fP. .TP \fBEINVAL\fP حُددت \fBCLONE_NEWPID\fP مع واحدة (أو كلتا) \fBCLONE_THREAD\fP أو \fBCLONE_PARENT\fP في قناع \fIflags\fP. .TP \fBEINVAL\fP كلا \fBCLONE_NEWUSER\fP و \fBCLONE_THREAD\fP حُددا في قناع \fIflags\fP. .TP \fBEINVAL\fP (منذ لينكس 2.6.32) .\" commit 123be07b0b399670a7cc3d82fef0cb4f93ef885c حُددت \fBCLONE_PARENT\fP، وكان المستدعِي هو عملية init. .TP \fBEINVAL\fP تُعيدها دالة غلاف \fBclone\fP() في glibc عندما يُحدد \fIfn\fP أو \fIstack\fP كقيمة NULL. .TP \fBEINVAL\fP حُددت \fBCLONE_NEWIPC\fP في قناع \fIflags\fP، لكن النواة لم تُضبط مع خيارات \fBCONFIG_SYSVIPC\fP و \fBCONFIG_IPC_NS\fP. .TP \fBEINVAL\fP حُددت \fBCLONE_NEWNET\fP في قناع \fIflags\fP، لكن النواة لم تُضبط مع خيار \fBCONFIG_NET_NS\fP. .TP \fBEINVAL\fP حُددت \fBCLONE_NEWPID\fP في قناع \fIflags\fP، لكن النواة لم تُضبط مع خيار \fBCONFIG_PID_NS\fP. .TP \fBEINVAL\fP حُددت \fBCLONE_NEWUSER\fP في قناع \fIflags\fP، لكن النواة لم تُضبط مع خيار \fBCONFIG_USER_NS\fP. .TP \fBEINVAL\fP حُددت \fBCLONE_NEWUTS\fP في قناع \fIflags\fP، لكن النواة لم تُضبط مع خيار \fBCONFIG_UTS_NS\fP. .TP \fBEINVAL\fP الكدس \fIstack\fP غير محاذٍ لحدود مناسبة لهذه المعمارية. على سبيل المثال، في معمارية aarch64، يجب أن يكون \fIstack\fP من مضاعفات 16. .TP \fBEINVAL\fP (في \fBclone3\fP() فقط) حُددت \fBCLONE_DETACHED\fP في قناع \fIflags\fP. .TP \fBEINVAL\fP (في \fBclone\fP() فقط) حُددت \fBCLONE_PIDFD\fP مع \fBCLONE_DETACHED\fP في قناع \fIflags\fP. .TP \fBEINVAL\fP (قبل لينكس 6.9) حُددت \fBCLONE_PIDFD\fP مع \fBCLONE_THREAD\fP في قناع \fIflags\fP. .TP \fBEINVAL\fP (في \fBclone\fP() فقط) حُددت \fBCLONE_PIDFD\fP مع \fBCLONE_PARENT_SETTID\fP في قناع \fIflags\fP. .TP \fBEINVAL\fP (في \fBclone3\fP() فقط) حجم \fIset_tid_size\fP أكبر من عدد مساحات أسماء PID المتداخلة. .TP \fBEINVAL\fP (في \fBclone3\fP() فقط) أحد معرفات العمليات (PIDs) المحددة في \fIset_tid\fP غير صالح. .TP \fBEINVAL\fP (في \fBclone3\fP() فقط) .\" commit 7f192e3cd316ba58c88dfa26796cf77789dd9872 حُددت \fBCLONE_THREAD\fP أو \fBCLONE_PARENT\fP في قناع \fIflags\fP، ولكن حُددت إشارة في \fIexit_signal\fP. .TP \fBEINVAL\fP (في AArch64 فقط، لينكس 4.6 وما قبله) الكدس \fIstack\fP لم يكن محاذيًا لحدود 128 بت. .TP \fBENOMEM\fP تعذر تخصيص ذاكرة كافية لتخصيص بنية مهمة للعملية الوليدة، أو لنسخ أجزاء سياق المستدعِي التي يجب نسخها. .TP \fBENOSPC\fP (منذ لينكس 3.7) .\" commit f2302505775fd13ba93f034206f1e2a587017929 حُددت \fBCLONE_NEWPID\fP في قناع \fIflags\fP، ولكن كان سيتم تجاوز الحد الأقصى لعمق تداخل مساحات أسماء PID؛ انظر \fBpid_namespaces\fP(7). .TP \fBENOSPC\fP (منذ لينكس 4.9؛ قبله \fBEUSERS\fP) حُددت \fBCLONE_NEWUSER\fP في قناع \fIflags\fP، وسيتسبب الاستدعاء في تجاوز الحد الأقصى لعدد مساحات أسماء المستخدمين المتداخلة. انظر \fBuser_namespaces\fP(7). .IP من لينكس 3.11 إلى لينكس 4.8، كان الخطأ الذي يُشخص في هذه الحالة هو \fBEUSERS\fP. .TP \fBENOSPC\fP (منذ لينكس 4.9) إحدى القيم في قناع \fIflags\fP حددت إنشاء مساحة أسماء مستخدم جديدة، ولكن القيام بذلك كان سيؤدي إلى تجاوز الحد المحدد بواسطة الملف المقابل في \fI/proc/sys/user\fP. لمزيد من التفاصيل، انظر \fBnamespaces\fP(7). .TP \fBEOPNOTSUPP\fP (في \fBclone3\fP() فقط) حُددت \fBCLONE_INTO_CGROUP\fP في \fIcl_args.flags\fP، لكن واصف الملف المحدد في \fIcl_args.cgroup\fP يشير إلى مجموعة تحكم (cgroup) من الإصدار 2 في حالة \fIdomain invalid\fP. .TP \fBEPERM\fP حُددت \fBCLONE_NEWCGROUP\fP أو \fBCLONE_NEWIPC\fP أو \fBCLONE_NEWNET\fP أو \fBCLONE_NEWNS\fP أو \fBCLONE_NEWPID\fP أو \fBCLONE_NEWUTS\fP بواسطة عملية غير مميزة (عملية بدون \fBCAP_SYS_ADMIN\fP). .TP \fBEPERM\fP حُددت \fBCLONE_PID\fP بواسطة عملية غير العملية 0. (يحدث هذا الخطأ فقط في لينكس 2.5.15 وما قبله). .TP \fBEPERM\fP حُددت \fBCLONE_NEWUSER\fP في قناع \fIflags\fP، ولكن إما معرف المستخدم الفعلي أو معرف المجموعة الفعلي للمستدعِي ليس له خريطة مقابلة (mapping) في مساحة أسماء الأب (انظر \fBuser_namespaces\fP(7)). .TP \fBEPERM\fP (منذ لينكس 3.9) .\" commit 3151527ee007b73a0ebd296010f1c0454a919c7d .\" FIXME What is the rationale for this restriction? حُددت \fBCLONE_NEWUSER\fP في قناع \fIflags\fP وكان المستدعِي في بيئة chroot (أي أن دليل الجذر للمستدعِي لا يطابق دليل الجذر لمساحة أسماء الوصل التي يقيم فيها). .TP \fBEPERM\fP (في \fBclone3\fP() فقط) كان \fIset_tid_size\fP أكبر من صفر، ويفتقر المستدعِي إلى قدرة \fBCAP_SYS_ADMIN\fP في واحدة أو أكثر من مساحات أسماء المستخدمين التي تمتلك مساحات أسماء PID المقابلة. .TP \fBERESTARTNOINTR\fP (منذ لينكس 2.6.17) .\" commit 4a2c7a7837da1b91468e50426066d988050e4d56 قُطِعَ استدعاء النظام بواسطة إشارة وسيُعاد تشغيله. (لا يمكن رؤية هذا إلا أثناء التتبع trace.) .TP \fBEUSERS\fP (لينكس 3.11 إلى لينكس 4.8) حُددت \fBCLONE_NEWUSER\fP في قناع \fIflags\fP، وسيتم تجاوز الحد الأقصى لعدد مساحات أسماء المستخدمين المتداخلة. انظر مناقشة خطأ \fBENOSPC\fP أعلاه. .SH الإصدارات تجري دالة غلاف \fBclone\fP() في glibc بعض التغييرات في الذاكرة التي يشير إليها \fIstack\fP (التغييرات المطلوبة لإعداد الكدس بشكل صحيح للوليد) \fIقبل\fP استدعاء نظام \fBclone\fP(). لذا، في الحالات التي يُستخدم فيها \fBclone\fP() لإنشاء عمليات وليدة بشكل تكراري، لا تستخدم المخزن المؤقت المستخدم لكدس الأب ككدس للعملية الوليدة. .P في i386، لا ينبغي استدعاء \fBclone\fP() من خلال vsyscall، بل مباشرة من خلال \fIint $0x80\fP. .SS "الاختلافات بين مكتبة C والنواة" استدعاء نظام \fBclone\fP() الخام يتوافق بشكل أوثق مع \fBfork\fP(2) من حيث أن التنفيذ في العملية الوليدة يستمر من نقطة الاستدعاء. وعلى هذا النحو، تُحذف المعطيات \fIfn\fP و \fIarg\fP الخاصة بدالة غلاف \fBclone\fP(). .P على عكس غلاف glibc، يقبل استدعاء نظام \fBclone\fP() الخام NULL كمعطى لـ \fIstack\fP (وبالمثل يسمح \fBclone3\fP() لـ \fIcl_args.stack\fP بأن يكون NULL). وفي هذه الحالة، تستخدم العملية الوليدة نسخة مكررة من كدس الأب. (تضمن دلالات النسخ عند الكتابة Copy\-on\-write أن تحصل العملية الوليدة على نسخ منفصلة من صفحات الكدس عندما تقوم أي من العمليتين بتعديل الكدس). وفي هذه الحالة، لضمان التشغيل الصحيح، لا ينبغي تحديد خيار \fBCLONE_VM\fP. (إذا كانت العملية الوليدة \fIتتشارك\fP ذاكرة الأب بسبب استخدام علامة \fBCLONE_VM\fP، فلن يحدث تكرار بالنسخ عند الكتابة ومن المرجح أن يؤدي ذلك إلى حدوث فوضى). .P يختلف ترتيب المعطيات أيضًا في استدعاء النظام الخام، وهناك اختلافات في المعطيات عبر المعماريات المختلفة، كما هو مفصل في الفقرات التالية. .P واجهة استدعاء النظام الخام في x86\-64 وبعض المعماريات الأخرى (بما في ذلك sh و tile و alpha) هي: .P .in +4n .EX \fBlong clone(unsigned long \fP\fIflags\fP\fB, void *\fP\fIstack\fP\fB,\fP \fB int *\fP\fIparent_tid\fP\fB, int *\fP\fIchild_tid\fP\fB,\fP \fB unsigned long \fP\fItls\fP\fB);\fP .EE .in .P .\" CONFIG_CLONE_BACKWARDS في x86\-32 وعدة معماريات شائعة أخرى (بما في ذلك score و ARM و ARM 64 و PA\-RISC و arc و Power PC و xtensa و MIPS)، ينعكس ترتيب آخر معطيين: .P .in +4n .EX \fBlong clone(unsigned long \fP\fIflags\fP\fB, void *\fP\fIstack\fP\fB,\fP \fB int *\fP\fIparent_tid\fP\fB, unsigned long \fP\fItls\fP\fB,\fP \fB int *\fP\fIchild_tid\fP\fB);\fP .EE .in .P .\" CONFIG_CLONE_BACKWARDS2 في معماريتي cris و s390، ينعكس ترتيب أول معطيين: .P .in +4n .EX \fBlong clone(void *\fP\fIstack\fP\fB, unsigned long \fP\fIflags\fP\fB,\fP \fB int *\fP\fIparent_tid\fP\fB, int *\fP\fIchild_tid\fP\fB,\fP \fB unsigned long \fP\fItls\fP\fB);\fP .EE .in .P .\" CONFIG_CLONE_BACKWARDS3 في معمارية microblaze، يُزوّد معطى إضافي: .P .in +4n .EX \fBlong clone(unsigned long \fP\fIflags\fP\fB, void *\fP\fIstack\fP\fB,\fP \fB int \fP\fIstack_size\fP\fB,\fP\f[R] /* حجم الكدس */\fR \fB int *\fP\fIparent_tid\fP\fB, int *\fP\fIchild_tid\fP\fB,\fP \fB unsigned long \fP\fItls\fP\fB);\fP .EE .in .\" .SS "blackfin و m68k و sparc" .\" Mike Frysinger noted in a 2013 mail: .\" these arches don't define __ARCH_WANT_SYS_CLONE: .\" blackfin ia64 m68k sparc اتفاقيات تمرير المعطيات في blackfin و m68k و sparc تختلف عن الأوصاف أعلاه. لمزيد من التفاصيل، انظر مصدر النواة (و glibc). .SH المعايير لينكس. .SH التاريخ .TP \fBclone3\fP() .\" There is no entry for .\" .BR clone () .\" in libc5. .\" glibc2 provides .\" .BR clone () .\" as described in this manual page. لينكس 5.3. .SS "لينكس 2.4 وما قبله" في سلسلة لينكس 2.4.x، لا تجعل \fBCLONE_THREAD\fP بشكل عام أب الخيط الجديد هو نفس أب العملية المستدعية. ومع ذلك، من لينكس 2.4.7 إلى لينكس 2.4.18، كانت علامة \fBCLONE_THREAD\fP تتضمن علامة \fBCLONE_PARENT\fP (كما هو الحال في لينكس 2.6.0 وما بعده). .P في لينكس 2.4 وما قبله، لا يأخذ \fBclone\fP() المعطيات \fIparent_tid\fP و \fItls\fP و \fIchild_tid\fP. .SS ia64 في ia64، تُستخدم واجهة مختلفة: .P .in +4n .EX \fBint __clone2(typeof(int (void *)) *\fP\fIfn\fP\fB,\fP \fB void *\fP\fIstack_base\fP\fB, size_t \fP\fIstack_size\fP\fB,\fP \fB int \fP\fIflags\fP\fB, void *\fP\fIarg\fP\fB, ...\fP \fB \fP\f[R]/*\fB pid_t *\fP\fIparent_tid\fP\fB, struct user_desc *\fP\fItls\fP\fB,\fP \fB pid_t *\fP\fIchild_tid\fP\fB \fP\f[R]*/\fB );\fP .EE .in .P النموذج المبدئي الموضح أعلاه هو لدالة غلاف glibc؛ أما بالنسبة لنداء النظام نفسه، فيمكن وصف النموذج المبدئي على النحو التالي (وهو مطابق لنموذج \fBclone\fP() المبدئي على microblaze): .P .in +4n .EX \fBlong clone2(unsigned long \fP\fIflags\fP\fB, void *\fP\fIstack_base\fP\fB,\fP \fB int \fP\fIstack_size\fP\fB,\fP\f[R] /* حجم المكدس */\fR \fB int *\fP\fIparent_tid\fP\fB, int *\fP\fIchild_tid\fP\fB,\fP \fB unsigned long \fP\fItls\fP\fB);\fP .EE .in .P تعمل \fB__clone2\fP() بنفس طريقة \fBclone\fP()، باستثناء أن \fIstack_base\fP يشير إلى أدنى عنوان في منطقة مكدس الابن، ويحدد \fIstack_size\fP حجم المكدس الذي يشير إليه \fIstack_base\fP. .SH ملاحظات أحد استخدامات نداءات النظام هذه هو تنفيذ الخيوط: تدفقات متعددة للتحكم في برنامج يعمل بالتزامن في مساحة عناوين مشتركة. .P يمكن استخدام نداء النظام \fBkcmp\fP(2) لاختبار ما إذا كانت عمليتان تتشاركان موارد مختلفة مثل جدول واصفات الملفات، أو عمليات تراجع سيمافور System V، أو مساحة عناوين افتراضية. .P المناولات المسجلة باستخدام \fBpthread_atfork\fP(3) لا تُنفذ أثناء نداء clone. .SH العلل احتوت إصدارات مكتبة GNU C من 2.3.4 وحتى 2.24 (بما في ذلك هذا الإصدار) على دالة غلاف لـ \fBgetpid\fP(2) تؤدي عملية تخزين في خبيئة لمعرفات العمليات (PIDs). اعتمد هذا التخزين في الخبيئة على دعم في غلاف glibc للدالة \fBclone\fP()، ولكن القيود في التنفيذ جعلت الخبيئة غير محدثة في بعض الظروف. وعلى وجه الخصوص، إذا وُصل إشعار (إشارة) إلى الابن فور استدعاء \fBclone\fP()، فإن استدعاء \fBgetpid\fP(2) في معالج ذلك الإشعار قد يعيد معرف العملية للمستدعِي («الأب»)، إذا لم يتح لغلاف الاستنساخ فرصة لتحديث خبيئة معرف العملية في الابن بعد. (يتجاهل هذا النقاش الحالة التي يُنشأ فيها الابن باستخدام \fBCLONE_THREAD\fP، حيث \fIينبغي\fP أن تعيد \fBgetpid\fP(2) القيمة نفسها في الابن وفي العملية التي استدعت \fBclone\fP()، بما أن المستدعِي والابن في مجموعة الخيوط نفسها. كما لا تحدث مشكلة الخبيئة القديمة إذا تضمنت معطاة \fIflags\fP الوسم \fBCLONE_VM\fP.) وللحصول على الحقيقة، كان من الضروري أحيانًا استخدام كود مثل الآتي: .P .in +4n .EX #include \& pid_t mypid; \& mypid = syscall(SYS_getpid); .EE .in .\" See also the following bug reports .\" https://bugzilla.redhat.com/show_bug.cgi?id=417521 .\" http://sourceware.org/bugzilla/show_bug.cgi?id=6910 .P بسبب مشكلة الخبيئة القديمة، بالإضافة إلى مشكلات أخرى لوحظت في \fBgetpid\fP(2)، أُزيلت ميزة تخزين معرف العملية في الخبيئة في الإصدار 2.25 من glibc. .SH أمثلة يوضح البرنامج التالي استخدام \fBclone\fP() لإنشاء عملية ابن تعمل في مساحة أسماء UTS منفصلة. يغير الابن اسم المضيف في مساحة أسماء UTS الخاصة به. ثم يعرض كل من الأب والابن اسم مضيف النظام، مما يسمح برؤية اختلاف اسم المضيف في مساحات أسماء UTS للأب والابن. لمثال على استخدام هذا البرنامج، انظر \fBsetns\fP(2). .P داخل البرنامج النموذجي، نخصص الذاكرة التي ستُستخدم مكدسًا للابن باستخدام \fBmmap\fP(2) بدلاً من \fBmalloc\fP(3) للأسباب الرئيسة التالية: .IP \[bu] 3 تخصص \fBmmap\fP(2) كتلة من الذاكرة تبدأ عند حدود الصفحة وتكون من مضاعفات حجم الصفحة. وهذا مفيد إذا أردنا إنشاء صفحة حماية (صفحة ذات حماية \fBPROT_NONE\fP) في نهاية المكدس باستخدام \fBmprotect\fP(2). .IP \[bu] يمكننا تحديد العلم \fBMAP_STACK\fP لطلب تخطيط مناسب للمكدس. في الوقت الحالي، هذا العلم لا يقوم بأي عملية (no\-op) على لينكس، ولكنه موجود وله تأثير على بعض الأنظمة الأخرى، لذا ينبغي لنا تضمينه من أجل قابلية النقل. .SS "مصدر البرنامج" .\" SRC BEGIN (clone.c) .EX #define _GNU_SOURCE #include #include #include #include #include #include #include #include #include #include #include #include \& static int /* دالة البدء للابن المنسوخ */ childFunc(void *arg) { struct utsname uts; \& /* غيّر اسم المضيف في نطاق أسماء UTS للابن. */ \& if (sethostname(arg, strlen(arg)) == \-1) err(EXIT_FAILURE, "sethostname"); \& /* استرجع واعرض اسم المضيف. */ \& if (uname(&uts) == \-1) err(EXIT_FAILURE, "uname"); printf("uts.nodename in child: %s\[rs]n", uts.nodename); \& /* أبقِ نطاق الأسماء مفتوحًا لفترة عبر النوم. يسمح هذا ببعض التجارب\-\-على سبيل المثال، قد تنضم عملية أخرى إلى نطاق الأسماء. */ \& sleep(200); \& return 0; /* ينتهي الابن الآن */ } \& #define STACK_SIZE (1024 * 1024) /* حجم المكدس للابن المنسوخ */ \& int main(int argc, char *argv[]) { char *stack; /* بداية مخزن المكدس */ char *stackTop; /* نهاية مخزن المكدس */ pid_t pid; struct utsname uts; \& if (argc < 2) { fprintf(stderr, "Usage: %s \[rs]n", argv[0]); exit(EXIT_SUCCESS); } \& /* خصص ذاكرة لتستخدم كمكدس للابن. */ \& stack = mmap(NULL, STACK_SIZE, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS | MAP_STACK, \-1, 0); if (stack == MAP_FAILED) err(EXIT_FAILURE, "mmap"); \& stackTop = stack + STACK_SIZE; /* نفترض أن المكدس ينمو لأسفل */ \& /* أنشئ ابنًا له نطاق أسماء UTS الخاص به؛ يبدأ الابن التنفيذ في childFunc(). */ \& pid = clone(childFunc, stackTop, CLONE_NEWUTS | SIGCHLD, argv[1]); if (pid == \-1) err(EXIT_FAILURE, "clone"); if (munmap(stack, STACK_SIZE)) err(EXIT_FAILURE, "munmap"); printf("clone() returned %jd\[rs]n", (intmax_t) pid); \& /* يسقط الأب إلى هنا */ \& sleep(1); /* أعطِ الابن وقتًا لتغيير اسم مضيفه */ \& /* اعرض اسم المضيف في نطاق أسماء UTS للأب. سيكون هذا مختلفًا عن اسم المضيف في نطاق أسماء UTS للابن. */ \& if (uname(&uts) == \-1) err(EXIT_FAILURE, "uname"); printf("uts.nodename in parent: %s\[rs]n", uts.nodename); \& if (waitpid(pid, NULL, 0) == \-1) /* انتظر الابن */ err(EXIT_FAILURE, "waitpid"); printf("child has terminated\[rs]n"); \& exit(EXIT_SUCCESS); } .EE .\" SRC END .SH "انظر أيضًا" \fBfork\fP(2), \fBfutex\fP(2), \fBgetpid\fP(2), \fBgettid\fP(2), \fBkcmp\fP(2), \fBmmap\fP(2), \fBpidfd_open\fP(2), \fBset_thread_area\fP(2), \fBset_tid_address\fP(2), \fBsetns\fP(2), \fBtkill\fP(2), \fBunshare\fP(2), \fBwait\fP(2), \fBcapabilities\fP(7), \fBnamespaces\fP(7), \fBpthreads\fP(7) .PP .SH ترجمة تُرجمت هذه الصفحة من الدليل بواسطة زايد السعيدي . .PP هذه الترجمة هي وثيقة مجانية؛ راجع .UR https://www.gnu.org/licenses/gpl-3.0.html رخصة جنو العامة الإصدار 3 .UE أو ما بعده للاطلاع على شروط حقوق النشر. لا توجد أي ضمانات. .PP إذا وجدت أي أخطاء في ترجمة صفحة الدليل هذه، يرجى إرسال بريد إلكتروني إلى قائمة بريد المترجمين: .MT kde-l10n-ar@kde.org .ME .