- unstable 4.31.0-1
| getrlimit(2) | System Calls Manual | getrlimit(2) |
الاسم¶
getrlimit, setrlimit, prlimit - الحصول/تعيين حدود الموارد
المكتبة¶
مكتبة سي المعيارية (libc، -lc)
موجز¶
#include <sys/resource.h>
int getrlimit(int resource, struct rlimit *rlim); int setrlimit(int resource, const struct rlimit *rlim);
int prlimit(pid_t pid, int resource,
const struct rlimit *_Nullable new_limit,
struct rlimit *_Nullable old_limit);
struct rlimit {
rlim_t rlim_cur; /* الحد الناعم */
rlim_t rlim_max; /* الحد الصلب (سقف لـ rlim_cur) */
};
typedef /* ... */ rlim_t; /* Unsigned integer type */
prlimit():
_GNU_SOURCE
الوصف¶
استدعاءات النظام getrlimit() و setrlimit() تحصل وتضبط حدود الموارد. كل مورد له حد ناعم وصلب مرتبط به، كما هو معرف بهيكل rlimit.
الحد الناعم هو القيمة التي يفرضها النواة للمورد المقابل. الحد الصلب يعمل كسقف للحد الناعم: عملية غير مميزة يمكنها فقط ضبط حدها الناعم إلى قيمة في النطاق من 0 حتى الحد الصلب، وخفض حدها الصلب (بشكل لا رجعة فيه). عملية مميزة (تحت لينكس: تلك التي تملك قدرة CAP_SYS_RESOURCE في مساحة المستخدم الأولية) يمكنها إجراء تغييرات عشوائية على أي من قيمتي الحد.
القيمة RLIM_INFINITY تشير إلى عدم وجود حد على مورد (سواء في الهيكل الذي يعيده getrlimit() أو في الهيكل الذي يمرر إلى setrlimit()).
وسيطة resource يجب أن تكون واحدة من:
- RLIMIT_AS
- هذا هو الحجم الأقصى للذاكرة الافتراضية للعملية (مساحة العناوين). الحد محدد بالبايتات، ويتم تقريبه لأسفل إلى حجم صفحة النظام. هذا الحد يؤثر على استدعاءات brk(2)، mmap(2)، و mremap(2)، التي تفشل مع الخطأ ENOMEM عند تجاوز هذا الحد. بالإضافة إلى ذلك، فشل التوسع التلقائي للمكدس (ويولد SIGSEGV الذي يقتل العملية إذا لم يتم توفير مكدس بديل عبر sigaltstack(2)). نظرًا لأن القيمة من نوع long، على الأجهزة ذات long 32 بت، إما أن هذا الحد هو على الأكثر 2 جيبي بايت، أو أن هذا المورد غير محدود.
- RLIMIT_CORE
- هذا هو الحجم الأقصى لملف core (انظر core(5)) بالبايتات الذي يمكن للعملية تفريغه. عندما يكون 0، لا يتم إنشاء ملفات تفريغ أساسية. عندما يكون غير صفري، يتم اقتطاع التفريغات الأكبر إلى هذا الحجم.
- RLIMIT_CPU
- هذا هو حد، بالثواني، على مقدار وقت وحدة المعالجة المركزية الذي يمكن للعملية استهلاكه. عندما تصل العملية إلى الحد الناعم، يتم إرسال إشارة SIGXCPU إليها. الإجراء المبدئي لهذه الإشارة هو إنهاء العملية. ومع ذلك، يمكن التقاط الإشارة، ويمكن للمعالج إعادة التحكم إلى البرنامج الرئيسي. إذا استمرت العملية في استهلاك وقت وحدة المعالجة المركزية، سيتم إرسال SIGXCPU مرة واحدة في الثانية حتى يتم الوصول إلى الحد الصلب، وعندها يتم إرسال SIGKILL. (هذه النقطة الأخيرة تصف سلوك لينكس. تختلف التطبيقات في كيفية معالجتها للعمليات التي تستمر في استهلاك وقت وحدة المعالجة المركزية بعد الوصول إلى الحد الناعم. التطبيقات المحمولة التي تحتاج إلى التقاط هذه الإشارة يجب أن تقوم بإنهاء منظم عند أول استقبال لـ SIGXCPU.)
- RLIMIT_DATA
- هذا هو الحجم الأقصى لقطاع البيانات للعملية (البيانات المهيأة، البيانات غير المهيأة، والكومة). الحد محدد بالبايتات، ويتم تقريبه لأسفل إلى حجم صفحة النظام. هذا الحد يؤثر على استدعاءات brk(2)، sbrk(2)، و (منذ لينكس 4.7) mmap(2)، التي تفشل مع الخطأ ENOMEM عند مواجهة الحد الناعم لهذا المورد.
- RLIMIT_FSIZE
- هذا هو الحجم الأقصى بالبايتات للملفات التي يمكن للعملية إنشاؤها. محاولات تمديد ملف يتجاوز هذا الحد تؤدي إلى تسليم إشارة SIGXFSZ. بشكل مبدئي، هذه الإشارة تنهي العملية، ولكن يمكن للعملية التقاط هذه الإشارة بدلاً من ذلك، وفي هذه الحالة يفشل استدعاء النظام ذو الصلة (مثل write(2)، truncate(2)) مع الخطأ EFBIG.
- RLIMIT_LOCKS (لينكس 2.4.0 إلى لينكس 2.4.24)
- هذا هو حد على العدد المجمع لأقفال flock(2) وعقود إيجار fcntl(2) التي يمكن لهذه العملية إنشاؤها.
- RLIMIT_MEMLOCK
- هذا هو الحد الأقصى لعدد بايتات الذاكرة التي يمكن قفلها في ذاكرة الوصول العشوائي. هذا الحد يتم تقريبه لأسفل إلى أقرب مضاعف لحجم صفحة النظام. هذا الحد يؤثر على mlock(2)، mlockall(2)، وعملية mmap(2) MAP_LOCKED. منذ لينكس 2.6.9، يؤثر أيضًا على عملية shmctl(2) SHM_LOCK، حيث يضع حدًا أقصى على إجمالي البايتات في قطاعات الذاكرة المشتركة (انظر shmget(2)) التي يمكن قفلها بواسطة معرف المستخدم الحقيقي للعملية المستدعية. أقفال shmctl(2) SHM_LOCK تحسب بشكل منفصل عن أقفال الذاكرة لكل عملية التي تم إنشاؤها بواسطة mlock(2)، mlockall(2)، و mmap(2) MAP_LOCKED؛ يمكن للعملية قفل بايتات حتى هذا الحد في كل من هاتين الفئتين.
- قبل لينكس 2.6.9، كان هذا الحد يتحكم في مقدار الذاكرة التي يمكن قفلها بواسطة عملية مميزة. منذ لينكس 2.6.9، لا يتم وضع حدود على مقدار الذاكرة التي يمكن لعملية مميزة قفلها، وبدلاً من ذلك يحكم هذا الحد مقدار الذاكرة التي يمكن لعملية غير مميزة قفلها.
- RLIMIT_MSGQUEUE (منذ لينكس 2.6.8)
- هذا هو حد على عدد البايتات التي يمكن تخصيصها لقوائم رسائل POSIX لمعرف المستخدم الحقيقي للعملية المستدعية. هذا الحد يتم فرضه لـ mq_open(3). كل قائمة رسائل ينشئها المستخدم تحسب (حتى يتم إزالتها) ضد هذا الحد وفقًا للصيغة:
- منذ لينكس 3.5:
-
bytes = attr.mq_maxmsg * sizeof(struct msg_msg) +
MIN(attr.mq_maxmsg, MQ_PRIO_MAX) *
sizeof(struct posix_msg_tree_node)+
/* للتحميل الإضافي */
attr.mq_maxmsg * attr.mq_msgsize;
/* لبيانات الرسالة */
- لينكس 3.4 وما قبله:
-
بايت = attr.mq_maxmsg * sizeof(struct msg_msg *) +
/* للتراكب */
attr.mq_maxmsg * attr.mq_msgsize;
/* لبيانات الرسالة */
- حيث attr هي بنية mq_attr المحددة كوسيطة رابعة لـ mq_open(3)، وبنيتا msg_msg و posix_msg_tree_node هما بنيتان داخليتان للنواة.
- المُضاف "التراكب" في الصيغة يحسب البايتات المطلوبة للتراكب من قبل التطبيق ويضمن أن المستخدم لا يمكنه إنشاء عدد غير محدود من الرسائل ذات الطول الصفري (مثل هذه الرسائل تستهلك مع ذلك بعض ذاكرة النظام لتراكب المحاسبة).
- RLIMIT_NICE (منذ لينكس 2.6.12، لكن انظر الأخطاء أدناه)
- يحدد هذا سقفًا يمكن رفع قيمة nice للعملية إليه باستخدام setpriority(2) أو nice(2). يُحسب السقف الفعلي لقيمة nice كـ 20 - rlim_cur. وبالتالي فإن النطاق المفيد لهذا الحد هو من 1 (المقابل لقيمة nice 19) إلى 40 (المقابل لقيمة nice -20). كان هذا الاختيار غير المعتاد للنطاق ضروريًا لأن الأرقام السالبة لا يمكن تحديدها كقيم حدود للموارد، حيث أن لها معاني خاصة عادةً. على سبيل المثال، RLIM_INFINITY عادةً ما يكون نفس -1. لمزيد من التفاصيل حول قيمة nice، انظر sched(7).
- RLIMIT_NOFILE
- يحدد هذا قيمة أكبر بواحد من الحد الأقصى لرقم واصف الملف الذي يمكن فتحه بواسطة هذه العملية. المحاولات (open(2)، pipe(2)، dup(2)، إلخ) لتجاوز هذا الحد تؤدي إلى الخطأ EMFILE. (تاريخيًا، كان هذا الحد يُسمى RLIMIT_OFILE على BSD.)
- منذ لينكس 4.5، يحدد هذا الحد أيضًا الحد الأقصى لعدد واصفات الملفات التي يمكن لعملية غير مميزة (بدون صلاحية CAP_SYS_RESOURCE) أن يكون لديها "قيد الإرسال" إلى عمليات أخرى، عن طريق تمريرها عبر مقابس نطاق UNIX. ينطبق هذا الحد على استدعاء النظام sendmsg(2). لمزيد من التفاصيل، انظر unix(7).
- RLIMIT_NPROC
- هذا حد على عدد العمليات الموجودة (أو، بشكل أدق على لينكس، الخيوط) لمعرف المستخدم الحقيقي للعملية المستدعية. طالما أن العدد الحالي للعمليات التابعة لمعرف المستخدم الحقيقي لهذه العملية أكبر من أو يساوي هذا الحد، يفشل fork(2) مع الخطأ EAGAIN.
- لا يُفرض حد RLIMIT_NPROC على العمليات التي لديها صلاحية CAP_SYS_ADMIN أو CAP_SYS_RESOURCE، أو تعمل بمعرف مستخدم حقيقي 0.
- RLIMIT_RSS
- هذا حد (بالبايت) على المجموعة المقيمة للعملية (عدد الصفحات الافتراضية المقيمة في RAM). لهذا الحد تأثير فقط في لينكس 2.4.x، x < 30، ويؤثر هناك فقط على استدعاءات madvise(2) التي تحدد MADV_WILLNEED.
- RLIMIT_RTPRIO (منذ لينكس 2.6.12، لكن انظر الأخطاء)
- يحدد هذا سقفًا للأولوية الزمنية الحقيقية التي يمكن تعيينها لهذه العملية باستخدام sched_setscheduler(2) و sched_setparam(2).
- لمزيد من التفاصيل حول سياسات الجدولة الزمنية الحقيقية، انظر sched(7)
- RLIMIT_RTTIME (منذ لينكس 2.6.25)
- هذا حد (بالميكروثانية) على مقدار وقت وحدة المعالجة المركزية الذي يمكن لعملية مجدولة تحت سياسة جدولة زمنية حقيقية استهلاكه دون إجراء استدعاء نظام حظر. لغرض هذا الحد، في كل مرة تقوم فيها عملية باستدعاء نظام حظر، يُعاد تعيين عدد وقت وحدة المعالجة المركزية المستهلك إلى الصفر. لا يُعاد تعيين عدد وقت وحدة المعالجة المركزية إذا استمرت العملية في محاولة استخدام وحدة المعالجة المركزية ولكن تم استباقها، أو انتهت شريحة وقتها، أو استدعت sched_yield(2).
- عند الوصول إلى الحد الناعم، تُرسل إشارة SIGXCPU إلى العملية. إذا التقطت العملية هذه الإشارة أو تجاهلتها واستمرت في استهلاك وقت وحدة المعالجة المركزية، فسيتم توليد SIGXCPU مرة كل ثانية حتى يتم الوصول إلى الحد الصلب، وعندها تُرسل إشارة SIGKILL إلى العملية.
- الاستخدام المقصود لهذا الحد هو إيقاف عملية زمنية حقيقية جامحة من تعطيل النظام.
- لمزيد من التفاصيل حول سياسات الجدولة الزمنية الحقيقية، انظر sched(7)
- RLIMIT_SIGPENDING (منذ لينكس 2.6.8)
- هذا حد على عدد الإشارات التي يمكن وضعها في قائمة الانتظار لمعرف المستخدم الحقيقي للعملية المستدعية. تُحسب كل من الإشارات القياسية والزمنية الحقيقية لغرض التحقق من هذا الحد. ومع ذلك، يُفرض الحد فقط لـ sigqueue(3); من الممكن دائمًا استخدام kill(2) لوضع نسخة واحدة من أي من الإشارات غير الموجودة بالفعل في قائمة انتظار العملية.
- RLIMIT_STACK
- هذا هو الحد الأقصى لحجم مكدس العملية، بالبايت. عند الوصول إلى هذا الحد، يتم توليد إشارة SIGSEGV. لمعالجة هذه الإشارة، يجب على العملية استخدام مكدس إشارات بديل (sigaltstack(2)).
- منذ لينكس 2.6.23، يحدد هذا الحد أيضًا مقدار المساحة المستخدمة لوسائط سطر الأوامر ومتغيرات البيئة للعملية؛ للتفاصيل، انظر execve(2).
prlimit()¶
استدعاء النظام الخاص بلينكس prlimit() يجمع ويوسع وظائف setrlimit() و getrlimit(). يمكن استخدامه لتعيين وجلب حدود الموارد لعملية عشوائية.
الوسيطة resource لها نفس المعنى كما في setrlimit() و getrlimit().
إذا كانت الوسيطة new_limit ليست NULL، فسيتم استخدام بنية rlimit التي تشير إليها لتعيين قيم جديدة للحدود الناعمة والصلبة لـ resource. إذا كانت الوسيطة old_limit ليست NULL، فإن استدعاءًا ناجحًا لـ prlimit() يضع الحدود الناعمة والصلبة السابقة لـ resource في بنية rlimit المشار إليها بواسطة old_limit.
الوسيطة pid تحدد معرف العملية التي سيعمل عليها الاستدعاء. إذا كان pid هو 0، فإن الاستدعاء ينطبق على العملية المستدعية. لتعيين أو جلب موارد عملية غير نفسها، يجب أن يكون لدى المستدعي صلاحية CAP_SYS_RESOURCE في مساحة اسم المستخدم للعملية التي يتم تغيير حدود مواردها، أو يجب أن تتطابق معرفات المستخدم الحقيقية والفعالة والمحفوظة للعملية الهدف مع معرف المستخدم الحقيقي للمستدعي و يجب أن تتطابق معرفات المجموعة الحقيقية والفعالة والمحفوظة للعملية الهدف مع معرف المجموعة الحقيقي للمستدعي.
قيمة الإرجاع¶
عند النجاح، تُرجع استدعاءات النظام هذه 0. عند الخطأ، يُرجع -1، ويتم تعيين errno للإشارة إلى الخطأ.
الأخطاء¶
- EFAULT
- وسيطة مؤشر تشير إلى موقع خارج مساحة العنوان القابلة للوصول.
- EINVAL
- القيمة المحددة في resource غير صالحة؛ أو، بالنسبة لـ setrlimit() أو prlimit(): كانت rlim->rlim_cur أكبر من rlim->rlim_max.
- EPERM
- حاولت عملية غير مميزة رفع الحد الصلب؛ القدرة CAP_SYS_RESOURCE مطلوبة لفعل ذلك.
- EPERM
- حاول المستدعي زيادة الحد الصلب RLIMIT_NOFILE فوق الحد الأقصى المعرف بواسطة /proc/sys/fs/nr_open (انظر proc(5))
- EPERM
- (prlimit()) لم تملك العملية المستدعية الإذن لتعيين الحدود للعملية المحددة بواسطة pid.
- ESRCH
- تعذر العثور على عملية بالمعرف المحدد في pid.
السمات¶
للاطلاع على شرح للمصطلحات المستخدمة في هذا القسم، انظر attributes(7).
| الواجهة | السمة | القيمة |
| getrlimit(), setrlimit(), prlimit() | سلامة الخيوط | MT-Safe |
المعايير¶
- getrlimit()
- setrlimit()
- POSIX.1-2024.
- prlimit()
- لينكس.
RLIMIT_MEMLOCK و RLIMIT_NPROC مشتقان من BSD وغير محددين في POSIX.1؛ هما موجودان على أنظمة BSD ولينكس، ولكن على عدد قليل من التطبيقات الأخرى. RLIMIT_RSS مشتق من BSD وغير محدد في POSIX.1؛ ومع ذلك فهو موجود على معظم التطبيقات. RLIMIT_MSGQUEUE، RLIMIT_NICE، RLIMIT_RTPRIO، RLIMIT_RTTIME، و RLIMIT_SIGPENDING خاصة بلينكس.
التاريخ¶
- getrlimit()
- setrlimit()
- 4.3BSD، SVr4، SUSv1، POSIX.1-2001 XSI، POSIX.1-2024.
- prlimit()
- لينكس 2.6.36، glibc 2.13.
ملاحظات¶
عملية ابنة منشأة عبر fork(2) ترث حدود موارد والديها. حدود الموارد محفوظة عبر execve(2).
حدود الموارد هي سمات لكل عملية مشتركة بين جميع الخيوط في العملية.
خفض الحد الناعم لمورد تحت الاستهلاك الحالي للعملية لذلك المورد سينجح (ولكن سيمنع العملية من زيادة استهلاكها للمورد أكثر).
يمكن للمرء تعيين حدود موارد الصدفة باستخدام الأمر المدمج ulimit (limit في csh(1)). حدود موارد الصدفة موروثة من قبل العمليات التي تنشئها لتنفيذ الأوامر.
منذ لينكس 2.6.24، يمكن فحص حدود موارد أي عملية عبر /proc/pid/limits؛ انظر proc(5).
قدمت الأنظمة القديمة دالة vlimit() بغرض مشابه لـ setrlimit(). للتوافق مع الإصدارات السابقة، يوفر glibc أيضًا vlimit(). يجب كتابة جميع التطبيقات الجديدة باستخدام setrlimit().
اختلافات ABI بين مكتبة C والنواة¶
منذ glibc 2.13، لم تعد دالتا الغلاف getrlimit() و setrlimit() في glibc تستدعيان استدعاءات النظام المقابلة، بل تستخدمان prlimit() بدلاً من ذلك، للأسباب الموصوفة في BUGS.
اسم دالة الغلاف في glibc هو prlimit()؛ استدعاء النظام الأساسي هو prlimit64().
العلل¶
في أنوية لينكس الأقدم، كانت الإشارات SIGXCPU و SIGKILL التي تُسلم عندما تواجه عملية الحدين الناعم والصلب RLIMIT_CPU تُسلم بعد ثانية (وحدة معالجة مركزية) واحدة مما ينبغي. تم إصلاح هذا في لينكس 2.6.8.
في أنوية لينكس 2.6.x قبل لينكس 2.6.17، يُعامل حد RLIMIT_CPU بقيمة 0 بشكل خاطئ على أنه "بدون حد" (مثل RLIM_INFINITY). منذ لينكس 2.6.17، تعيين حد بقيمة 0 له تأثير، ولكن يُعامل فعليًا كحد قدره ثانية واحدة.
خلل في النواة يعني أن RLIMIT_RTPRIO لا يعمل في لينكس 2.6.12؛ المشكلة مُصلحة في لينكس 2.6.13.
في لينكس 2.6.12، كان هناك عدم تطابق بفارق واحد بين نطاقات الأولوية التي تُرجعها getpriority(2) و RLIMIT_NICE. كان لهذا تأثير أن السقف الفعلي لقيمة nice يُحسب كـ 19 - rlim_cur. تم إصلاح هذا في لينكس 2.6.13.
منذ لينكس 2.6.12، إذا وصلت عملية إلى حدها الناعم RLIMIT_CPU وكان لديها معالج مثبت لـ SIGXCPU، فبالإضافة إلى استدعاء معالج الإشارة، تزيد النواة الحد الناعم بمقدار ثانية واحدة. يتكرر هذا السلوك إذا استمرت العملية في استهلاك وقت وحدة المعالجة المركزية، حتى الوصول إلى الحد الصلب، وعندها تُقتل العملية. لا تغير التطبيقات الأخرى الحد الناعم RLIMIT_CPU بهذه الطريقة، وسلوك لينكس ربما لا يتوافق مع المعايير؛ يجب على التطبيقات المحمولة تجنب الاعتماد على هذا السلوك الخاص بلينكس. يُظهر الحد الخاص بلينكس RLIMIT_RTTIME نفس السلوك عند مواجهة الحد الناعم.
لم تشخص أنوية لينكس قبل 2.4.22 الخطأ EINVAL لـ setrlimit() عندما كانت rlim->rlim_cur أكبر من rlim->rlim_max.
لا يُرجع لينكس خطأً عندما تفشل محاولة تعيين RLIMIT_CPU، لأسباب تتعلق بالتوافق.
تمثيل قيم حدود الموارد "الكبيرة" على منصات 32 بت¶
تستخدم دالتا الغلاف getrlimit() و setrlimit() في glibc نوع بيانات rlim_t بعرض 64 بت، حتى على منصات 32 بت. ومع ذلك، فإن نوع البيانات rlim_t المستخدم في استدعاءات النظام getrlimit() و setrlimit() هو unsigned long (32 بت). علاوة على ذلك، في لينكس، تمثل النواة حدود الموارد على منصات 32 بت كـ unsigned long. لكن نوع بيانات 32 بت ليس واسعًا بما يكفي. الحد الأكثر صلة هنا هو RLIMIT_FSIZE، الذي يحدد الحجم الأقصى الذي يمكن أن ينمو إليه ملف: ليكون مفيدًا، يجب تمثيل هذا الحد باستخدام نوع بعرض مثل النوع المستخدم لتمثيل إزاحات الملف—أي، بعرض مثل off_t بعرض 64 بت (بافتراض برنامج مُجمّع مع _FILE_OFFSET_BITS=64).
للتحايل على هذا القيد في النواة، إذا حاول برنامج تعيين حد مورد إلى قيمة أكبر مما يمكن تمثيله في unsigned long بعرض 32 بت، فإن دالة الغلاف setrlimit() في glibc حولت قيمة الحد بصمت إلى RLIM_INFINITY. بعبارة أخرى، تم تجاهل إعداد حد المورد المطلوب بصمت.
منذ إصدار glibc 2.13، يتجاوز glibc قيود استدعاءات النظام getrlimit() و setrlimit() عبر تنفيذ setrlimit() و getrlimit() كدوال غلاف تستدعي prlimit().
أمثلة¶
يوضح البرنامج التالي استخدام prlimit().
#define _GNU_SOURCE
#define _FILE_OFFSET_BITS 64
#include <err.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/resource.h>
#include <time.h>
int
main(int argc, char *argv[])
{
pid_t pid;
struct rlimit old, new;
struct rlimit *newp;
if (!(argc == 2 || argc == 4)) {
fprintf(stderr, "Usage: %s <pid> [<new-soft-limit> "
"<new-hard-limit>]\n", argv[0]);
exit(EXIT_FAILURE);
}
pid = atoi(argv[1]); /* PID of target process */
newp = NULL;
if (argc == 4) {
new.rlim_cur = atoi(argv[2]);
new.rlim_max = atoi(argv[3]);
newp = &new;
}
/* Set CPU time limit of target process; retrieve and display
previous limit */
if (prlimit(pid, RLIMIT_CPU, newp, &old) == -1)
err(EXIT_FAILURE, "prlimit-1");
printf("Previous limits: soft=%jd; hard=%jd\n",
(intmax_t) old.rlim_cur, (intmax_t) old.rlim_max);
/* Retrieve and display new CPU time limit */
if (prlimit(pid, RLIMIT_CPU, NULL, &old) == -1)
err(EXIT_FAILURE, "prlimit-2");
printf("New limits: soft=%jd; hard=%jd\n",
(intmax_t) old.rlim_cur, (intmax_t) old.rlim_max);
exit(EXIT_SUCCESS);
}
انظر أيضًا¶
prlimit(1), dup(2), fcntl(2), fork(2), getrusage(2), mlock(2), mmap(2), open(2), quotactl(2), sbrk(2), shmctl(2), malloc(3), sigqueue(3), ulimit(3), core(5), capabilities(7), cgroups(7), credentials(7), signal(7)
ترجمة¶
تُرجمت هذه الصفحة من الدليل بواسطة زايد السعيدي <zayed.alsaidi@gmail.com>
هذه الترجمة هي وثيقة مجانية؛ راجع رخصة جنو العامة الإصدار 3 أو ما بعده للاطلاع على شروط حقوق النشر. لا توجد أي ضمانات.
إذا وجدت أي أخطاء في ترجمة صفحة الدليل هذه، يرجى إرسال بريد إلكتروني إلى قائمة بريد المترجمين: kde-l10n-ar@kde.org.
| 8 فبراير 2026 | صفحات دليل لينكس 6.18 |