क्या आपके पास होने वाली ज़ोंबी प्रक्रियाओं की संख्या के लिए एक ऊपरी सीमा है?

Question

मैं एक HP-UX प्रणाली के साथ काम करता था और पुराने व्यवस्थापक ने मुझे बताया कि सिस्टम पर आपके द्वारा की जा सकने वाली ज़ोंबी प्रक्रियाओं की संख्या पर एक ऊपरी सीमा है, मेरा मानना ​​है कि 1024।

• क्या यह एक कठिन तथ्य है? मुझे लगता है कि आपके पास किसी भी संख्या में लाश हो सकती है जैसे कि आप किसी भी संख्या में प्रक्रियाएं कर सकते हैं ...?
• क्या यह डिस्ट्रो से डिस्ट्रो तक का अलग-अलग मूल्य है?
• यदि हम ऊपरी सीमा से टकराते हैं और एक और ज़ोंबी बनाने की कोशिश करते हैं तो क्या होता है?

Comments

इस ब्लॉग लेख के अनुसार लिनक्स पर एकमात्र सीमा PID की संख्या है, जो केवल संयोग से लाश को प्रभावित करती है।

— भामत

दोनों उत्तर नीचे उल्लेखित हैं ulimit -u। मैं थोड़ी देर के लिए उलझन में था क्योंकि man ulimitमुझे कोई उल्लेख नहीं के साथ एक सी दिनचर्या मिली -u। उल्लिखित अल्टीमेट वास्तव में एक बिल्ट-इन बैश टूल है और यह बैश मैनपेज में वर्णित है।

— इमानुएल बर्ग

Answer 1

मेरे पास HP-UX उपलब्ध नहीं है, और मैं कभी भी बड़ा HP-UX प्रशंसक नहीं रहा।

ऐसा प्रतीत होता है कि लिनक्स पर, प्रति-प्रक्रिया या शायद प्रति-उपयोगकर्ता सीमा पर कि कितने बच्चे प्रक्रिया मौजूद हैं। आप इसे limitZsh के साथ बिल्ट-इन ( ulimit -ubash में अनुरूप प्रतीत होता है ) के साथ देख सकते हैं :

1002 % limit
cputime         unlimited
filesize        unlimited
datasize        unlimited
stacksize       8MB
coredumpsize    0kB
memoryuse       unlimited
maxproc         16136
  ...

यह एक आर्क लिनक्स लैपटॉप पर है।

मैंने उस सीमा का परीक्षण करने के लिए एक छोटा सा कार्यक्रम लिखा:

#include <stdio.h>
#include <signal.h>
#include <unistd.h>
#include <errno.h>
#include <string.h>
#include <sys/types.h>
#include <sys/wait.h>

volatile int sigchld_cnt = 0;

voida
sigchld_hdlr(int signo)
{
        ++sigchld_cnt;
}

int
main(int ac, char **av)
{
        int looping = 1;
        int child_cnt = 0;
        int status;

        signal(SIGCHLD, sigchld_hdlr);

        printf("Parent PID %d\n", getpid());

        while (looping)
        {
                switch (fork())
                {
                case 0:
                        _exit(0);
                        break;
                case -1:
                        fprintf(stderr, "Problem with fork(), %d children: %s\n",
                                child_cnt, strerror(errno));
                        looping = 0;
                        break;
                default:
                        ++child_cnt;
                        break;
                }
        }

        fprintf(stderr, "Sleeping, forked %d child processes\n", child_cnt);
        fprintf(stderr, "Received %d sigchild\n", sigchld_cnt);
        sleep(10);

        looping = 1;
        do {
                int x = wait(&status);

                if (x != -1)
                        --child_cnt;
                else if (errno != EINTR) {
                        fprintf(stderr, "wait() problem %d children left: \%s\n",
                                child_cnt, strerror(errno));
                        looping = 0;
                }
        } while (looping);

        printf("%d children left, %d SIGCHLD\n", child_cnt, sigchld_cnt);

        return 0;
}

wait(2)पर्याप्त समय पर कॉल करके सभी लाश को "एकत्र" करना आश्चर्यजनक रूप से मुश्किल था । इसके अलावा, प्राप्त किए गए SIGCHLD संकेतों की संख्या कभी भी कांटे की गई बाल प्रक्रियाओं की संख्या के समान नहीं होती है: मेरा मानना ​​है कि लिनक्स कर्नेल कभी-कभी कई बहिष्कृत बाल प्रक्रियाओं के लिए 1 SIGCHLD भेजता है।

वैसे भी, मेरे Arch linux लैपटॉप पर, मुझे 16088 चाइल्ड प्रॉसेस कांटेक्ट किए गए हैं, और जो कि लाश की संख्या होनी चाहिए, जैसा कि प्रोग्राम नहीं करता है wait(2) सिग्नल हैंडलर में सिस्टम कॉल ।

मेरे स्लैकवेयर 12 सर्वर पर, मुझे 6076 बच्चे प्रक्रियाएं मिलती हैं, जो कि इसके मूल्य के साथ मेल खाती हैं maxproc 6079। मेरी उपयोगकर्ता आईडी में 2 अन्य प्रक्रियाएं चल रही हैं,sshd और Zsh। कार्यक्रम के पहले, गैर-ज़ोंबी उदाहरण के साथ-साथ यह 6079 बनाता है।

fork(2)सिस्टम कॉल एक "संसाधन अस्थायी रूप से अनुपलब्ध" त्रुटि के साथ विफल। मुझे कोई अन्य सबूत नहीं दिखता कि क्या संसाधन उपलब्ध नहीं है। अगर मैं अपना प्रोग्राम 2 अलग-अलग xterms में एक साथ चलाता हूं, तो मुझे कुछ अलग नंबर मिलते हैं, लेकिन वे एक ही नंबर को जोड़ते हैं जैसे कि मैं इसे एक xterm में चलाता हूं। मुझे लगता है कि यह प्रक्रिया है टेबल एंट्रीज, या स्वैप या कुछ सिस्टम-वाइड संसाधन, और न केवल एक मनमानी सीमा।

मेरे पास अभी इसे चलाने के लिए कुछ और नहीं है।

Answer 2

मुझे नहीं पता कि एचपी-यूएक्स की सीमाएं क्या हैं। मैं आपको बता सकता हूं कि तार्किक कार्यान्वयन एक अधिकतम आकार के साथ एक प्रक्रिया तालिका है। प्रक्रिया तालिका प्रविष्टियों की कुल संख्या सैद्धांतिक रूप से प्रक्रिया आईडी की सीमा तक सीमित है, लेकिन अधिकांश कार्यान्वयन में तालिका के लिए आकार की सीमा होती है, जो बहुत अधिक अधिकतम पैदावार देती है। अधिकांश यूनिक्स वेरिएंट की प्रक्रियाओं की संख्या पर प्रति-उपयोगकर्ता सीमा भी है; आप चलाकर सीमा देख सकते हैंulimit -u बैश में ।

मैं एक यूनिक्स प्रणाली से प्रक्रिया आईडी की संख्या (जिसमें वास्तविक प्रक्रिया के साथ-साथ लाश भी शामिल है) के बजाय, लाश पर एक अलग सीमा होने की उम्मीद नहीं करता। इसलिए जब एक प्रक्रिया मर जाती है और एक ज़ोंबी बन जाता है, तो यह सीमा को प्रभावित नहीं करता है: संसाधन (प्रक्रिया तालिका में प्रविष्टि) को आवंटित किया जाता है जब एक प्रक्रिया कांटे और प्रक्रिया समाप्त होने पर मुक्त हो जाती है।

Answer 3

मुझे लगता है कि आपके पास किसी भी संख्या में लाश हो सकती है जैसे कि आप किसी भी संख्या में प्रक्रियाएं कर सकते हैं ...?

एक ज़ोंबी प्रक्रिया अंत में एक प्रक्रिया है-एक विशेष अवस्था में- फिर ज़ोंबी प्रक्रिया प्रक्रिया तालिका की उपलब्धता और आकार तक सीमित है, नियमित प्रक्रियाओं के रूप में ।

क्या यह डिस्ट्रो से डिस्ट्रो तक का अलग-अलग मूल्य है?

निश्चित रूप से, कई अन्य मापदंडों के रूप में। आपको एक विशिष्ट आकार पर रिले नहीं करना चाहिए, या यदि यह कई ज़ोंबी प्रक्रिया को पकड़ने के लिए पर्याप्त बड़ा है। यदि आपको बहुत अधिक लाश मिल रही है, तो समाधान एक बड़ी मेज नहीं है, क्योंकि यह अंततः पूर्ण हो जाएगा। एक ज़ोंबी प्रक्रिया अपने आप में खराब नहीं होती है, लेकिन बहुत अधिक संचित ज़ोंबी प्रक्रियाएं एक "बुरी तरह से व्यवहार किए जाने वाले" कार्यक्रम का संकेत है जो इस तरह की ज़ोंबी प्रक्रियाओं की अनुमति दे रही है।

यदि हम ऊपरी सीमा से टकराते हैं और एक और ज़ोंबी बनाने की कोशिश करते हैं तो क्या होता है?

एक बार जब प्रक्रिया तालिका पूरी तरह से नियमित और ज़ोंबी प्रक्रिया होती है-, तो कोई भी नई-अनियमित प्रक्रिया नहीं बनाई जा सकती है, भले ही प्रणाली में पर्याप्त संसाधन हों -ememory, प्रोसेसर, आदि-। केवल कमी संसाधन प्रक्रिया तालिका में केवल एक प्रविष्टि है। पहले से ही चल रहे कार्यक्रमों को -इस तरह से "अच्छी तरह से व्यवहार किया" - जब वे एक उप-प्रक्रिया बनाने की आवश्यकता होती है, तो असफल होना शुरू हो जाएगा। नए प्रोग्राम शुरू नहीं किए जा सके और यहां तक ​​कि सिंगल कमांड चलाना भी विफल हो जाएगा।

Comments

Even running single commands would fail.-> यह एक बड़ा प्रभाव है।

— शिप्पू मोकादिम