एक साप्ताहिक क्रॉन जॉब का परीक्षण करें [बंद]


237

मेरे पास #!/bin/bashcron.week डायरेक्टरी में एक फाइल है।

अगर यह काम करता है तो परीक्षण करने का कोई तरीका है? 1 सप्ताह इंतजार नहीं कर सकता

मैं रूट के साथ डेबियन 6 पर हूं


4
क्या आप इसे कमांड लाइन पर चलाकर स्क्रिप्ट का परीक्षण नहीं कर सकते?
Frédéric Hamidi

5
बस अपने में एक अलग प्रविष्टि जोड़ें जो crontabआपकी फ़ाइल को हर कुछ मिनटों में चलाता है, देखें कि अपेक्षित परिणाम हैं या नहीं, और फिर अपने crontab से परीक्षण प्रविष्टि को हटा दें। कोशिशcrontab -e
davin

61
नहीं, इसे कमांड लाइन से चलाना एक अच्छा तरीका नहीं है। कमांड लाइन से स्क्रिप्ट चलाने की गारंटी नहीं है कि यह उसी तरह से चलेगा जैसे कि उपयोगकर्ता को क्रोन से चलाया गया था। यहां तक ​​कि अगर यह एक ही उपयोगकर्ता के रूप में चलता है, तो आप कभी भी निश्चित नहीं हो सकते हैं कि बाकी सब कुछ समान होगा। कमांड लाइन से काम करने वाले वर्णनों को क्रोन से चलाने पर सभी प्रकार के कारणों में विफल हो सकते हैं ।
andynormancx

8
"सभी प्रकार के" किया गया हो सकता है थोड़ा अतिशयोक्तिपूर्ण ... अनुमतियों और वातावरण चरों दो हैं दिमाग में वसंत, आप आसानी से हालांकि उपनाम की तरह अलग अलग अन्य प्रारंभिक स्थितियों हो सकता है
andynormancx

3
मैं बस एक नई क्रॉन नौकरी का परीक्षण कर रहा हूं, मैं "सभी प्रकार" में एक और आइटम जोड़ूंगा। यदि आपके पास bash_profile में चीजें हैं, तो वे क्रॉन जॉब में एक बार नहीं चलते हैं, जबकि कमांड लाइन से काम का परीक्षण पूरी तरह से काम करता है। मानक कमांड लाइन पर क्रॉन जॉब्स का परीक्षण करना एक अच्छी परीक्षा नहीं है।
औरऑर्मेनक्सएक्स

जवाबों:


233

बस क्रोन क्या करता है, निम्न को निम्नानुसार चलाएं root:

run-parts -v /etc/cron.weekly

... या यदि आपको "Not a directory: -v" त्रुटि प्राप्त होती है, तो अगले एक:

run-parts /etc/cron.weekly -v

विकल्प -vस्क्रिप्ट नामों को चलाने से पहले प्रिंट करता है।


4
अगर मैं -v विकल्प का उपयोग करता हूं, तो "नॉट ए डाइरेक्टरी: -v" एरर, मेरे सिस्टम में इस कमांड के लिए कोई मैन पेज नहीं है, -v का मतलब है वर्बोस राइट? मैं
अधिकतम

3
"एक निर्देशिका नहीं" त्रुटि से बचने के लिए, मुझे इसके बजाय करना था: रन-पार्ट्स /etc/cron.weekly -v
क्रेग हयात

22
लेकिन यह पर्यावरण के चर को ध्यान में नहीं रखता है जो कि crontab में सेट किया जा सकता है
fcurella

34
run-partsकिसी दिए गए निर्देशिका की स्क्रिप्ट चलाता है। क्रोन के साथ कुछ नहीं करना है।
निकोलस

23
यह वास्तव में उत्कीर्ण और स्वीकार नहीं किया जाना चाहिए था, स्क्रिप्ट चलाने से परे यह आपको यह बताने के लिए कुछ भी नहीं करता है कि क्या स्क्रिप्ट वास्तव में क्रोन से चलने पर काम करेगी। इस प्रश्न के अन्य उत्तरों में से एक में उत्कृष्ट crontest स्क्रिप्ट का उपयोग करें।
औरऑनॉर्मैंक्स

87

आपके प्रश्न के दायरे से परे एक मातम ... लेकिन यहाँ मैं क्या करूँ।

"मैं क्रॉन जॉब का परीक्षण कैसे कर सकता हूं?" प्रश्न बारीकी से जुड़ा हुआ है "मैं अन्य कार्यक्रमों द्वारा लॉन्च किए गए गैर-संवादात्मक संदर्भों में चलने वाली स्क्रिप्ट का परीक्षण कैसे कर सकता हूं?" क्रोन में, ट्रिगर कुछ समय की स्थिति है, लेकिन बहुत सारी अन्य * निक्स सुविधाएं गैर-संवादात्मक तरीकों से स्क्रिप्ट या स्क्रिप्ट के टुकड़े लॉन्च करती हैं, और अक्सर उन स्थितियों में जिनमें कुछ स्क्रिप्ट चलती हैं उनमें कुछ अप्रत्याशित होते हैं और बग को हल करने तक टूटने का कारण बनते हैं। (यह भी देखें: https://stackoverflow.com/a/17805088/237059 )

इस समस्या के लिए एक सामान्य दृष्टिकोण सहायक है।

मेरी पसंदीदा तकनीकों में से एक ऐसी स्क्रिप्ट का उपयोग करना है जिसे मैंने ' क्रेस्टेस्ट ' लिखा था । यह क्रोन के भीतर से एक GNU स्क्रीन सत्र के भीतर लक्ष्य कमांड लॉन्च करता है, ताकि आप एक अलग टर्मिनल के साथ संलग्न कर सकें कि क्या चल रहा है, स्क्रिप्ट के साथ बातचीत करें, यहां तक ​​कि डिबगर का उपयोग करें।

इसे सेट करने के लिए, आप अपने क्रॉस्टैब प्रविष्टि में "सभी सितारों" का उपयोग करेंगे, और कमांड लाइन पर पहले कमांड के रूप में क्रॉस्टेस्ट निर्दिष्ट करें, जैसे:

* * * * * crontest /command/to/be/tested --param1 --param2

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

यदि आपकी कमांड एक बैश स्क्रिप्ट है, तो आप इसके बजाय ऐसा कर सकते हैं:

* * * * * crontest --bashdb /command/to/be/tested --param1 --param2

अब, यदि आप "स्क्रीन-एक्स" के साथ संलग्न करते हैं, तो आपको एक इंटरैक्टिव बशब सत्र का सामना करना पड़ेगा, और आप कोड के माध्यम से कदम उठा सकते हैं, चर की जांच कर सकते हैं, आदि।

#!/bin/bash

# crontest
# See https://github.com/Stabledog/crontest for canonical source.

# Test wrapper for cron tasks.  The suggested use is:
#
#  1. When adding your cron job, use all 5 stars to make it run every minute
#  2. Wrap the command in crontest
#        
#
#  Example:
#
#  $ crontab -e
#     * * * * * /usr/local/bin/crontest $HOME/bin/my-new-script --myparams
#
#  Now, cron will run your job every minute, but crontest will only allow one
#  instance to run at a time.  
#
#  crontest always wraps the command in "screen -d -m" if possible, so you can
#  use "screen -x" to attach and interact with the job.   
#
#  If --bashdb is used, the command line will be passed to bashdb.  Thus you
#  can attach with "screen -x" and debug the remaining command in context.
#
#  NOTES:
#   - crontest can be used in other contexts, it doesn't have to be a cron job.
#       Any place where commands are invoked without an interactive terminal and
#       may need to be debugged.
#
#   - crontest writes its own stuff to /tmp/crontest.log
#
#   - If GNU screen isn't available, neither is --bashdb
#

crontestLog=/tmp/crontest.log
lockfile=$(if [[ -d /var/lock ]]; then echo /var/lock/crontest.lock; else echo /tmp/crontest.lock; fi )
useBashdb=false
useScreen=$( if which screen &>/dev/null; then echo true; else echo false; fi )
innerArgs="$@"
screenBin=$(which screen 2>/dev/null)

function errExit {
    echo "[-err-] $@" | tee -a $crontestLog >&2
}

function log {
    echo "[-stat-] $@" >> $crontestLog
}

function parseArgs {
    while [[ ! -z $1 ]]; do
        case $1 in
            --bashdb)
                if ! $useScreen; then
                    errExit "--bashdb invalid in crontest because GNU screen not installed"
                fi
                if ! which bashdb &>/dev/null; then
                    errExit "--bashdb invalid in crontest: no bashdb on the PATH"
                fi

                useBashdb=true
                ;;
            --)
                shift
                innerArgs="$@"
                return 0
                ;;
            *)
                innerArgs="$@"
                return 0
                ;;
        esac
        shift
    done
}

if [[ -z  $sourceMe ]]; then
    # Lock the lockfile (no, we do not wish to follow the standard
    # advice of wrapping this in a subshell!)
    exec 9>$lockfile
    flock -n 9 || exit 1

    # Zap any old log data:
    [[ -f $crontestLog ]] && rm -f $crontestLog

    parseArgs "$@"

    log "crontest starting at $(date)"
    log "Raw command line: $@"
    log "Inner args: $@"
    log "screenBin: $screenBin"
    log "useBashdb: $( if $useBashdb; then echo YES; else echo no; fi )"
    log "useScreen: $( if $useScreen; then echo YES; else echo no; fi )"

    # Were building a command line.
    cmdline=""

    # If screen is available, put the task inside a pseudo-terminal
    # owned by screen.  That allows the developer to do a "screen -x" to
    # interact with the running command:
    if $useScreen; then
        cmdline="$screenBin -D -m "
    fi

    # If bashdb is installed and --bashdb is specified on the command line,
    # pass the command to bashdb.  This allows the developer to do a "screen -x" to
    # interactively debug a bash shell script:
    if $useBashdb; then
        cmdline="$cmdline $(which bashdb) "
    fi

    # Finally, append the target command and params:
    cmdline="$cmdline $innerArgs"

    log "cmdline: $cmdline"


    # And run the whole schlock:
    $cmdline 

    res=$?

    log "Command result: $res"


    echo "[-result-] $(if [[ $res -eq 0 ]]; then echo ok; else echo fail; fi)" >> $crontestLog

    # Release the lock:
    9<&-
fi

2
बहुत बढ़िया, सही समाधान। अन्य सभी तकनीकों जो मैंने कोशिश कीं, वास्तव में काम नहीं किया, crontest ने समस्या को आसानी से हल किया।
औरऑनॉर्मैंक्स

1
यह वैसे भी मेरी ज़रूरत से ज़्यादा था, लेकिन एक महान समाधान के लिए +1 वैसे भी; अधिक बार चलाने के लिए क्रोन की स्थापना और / tmp को आउटपुट डंप करना मेरे मुद्दे को समझने के लिए पर्याप्त था।
jcollum

2
ठंडा। हाँ, बुलडोजर को फायर करने का कोई कारण नहीं है अगर आपको सिर्फ एक हाथ की कुदाल की ज़रूरत है :)
Stabledog

2
उत्तम सामग्री। मैक पर मुझे नोट करना था brew tap discoteq/discoteq; brew install flockऔर फिर स्क्रिप्ट का उपयोग करने के लिए संशोधित करना था/usr/local/bin/flock
क्लॉडिउ

1
अच्छी उपयोगिता! गैर-संवादात्मक संदर्भों में प्रमाणीकरण समस्याओं का निदान करने के लिए बहुत उपयोगी है।
एरिक ब्लम

44

क्रोन में कुछ सामान के बारे में गड़बड़ करने के बाद, जो तुरंत संगत नहीं था, मैंने पाया कि निम्न दृष्टिकोण डीबगिंग के लिए अच्छा था:

crontab -e

* * * * * /path/to/prog var1 var2 &>>/tmp/cron_debug_log.log

यह एक मिनट में एक बार कार्य चलाएगा और आप बस यह देखने के लिए /tmp/cron_debug_log.logफ़ाइल में देख सकते हैं कि क्या चल रहा है।

यह वास्तव में "फायर जॉब" नहीं है जिसे आप ढूंढ रहे हैं, लेकिन इससे मुझे एक स्क्रिप्ट को डीबग करने में बहुत मदद मिली जो पहले क्रॉन में काम नहीं करती थी।


9
मैं इस दृष्टिकोण की सिफारिश करूंगा। ज्यादातर मामलों में समस्या यह है कि आप त्रुटि नहीं देखते हैं।
योहान याकिमोविच

8
गलत लाइन, क्रोन शेल के लिए कोई वितरण बश का उपयोग नहीं करता है और इसलिए & >> काम नहीं करता है। मैं उपयोग करने के लिए सुझाव है कि >>/tmp/cron_debug_log.log 2>&1इसके बजाय
drizzt

1
आपका क्या मतलब है /path/to/prog- कौन सा ठेला?
नाथन

3
कार्यक्रम आप क्रोन के साथ चलाने जा रहे हैं। यह हो सकता है usr/home/myFancyScript.shया यह एक सरल हो सकता है ls, या जो आप नियमित रूप से चलाना चाहते हैं।
Automatico

इसने मेरे लिए काम किया। सब कुछ ठीक होने पर यह जाँचने के लिए एक त्वरित परीक्षण करना सबसे आसान तरीका था
अभिजीत

25

मैं एक लॉक फ़ाइल का उपयोग करता हूं और फिर हर मिनट चलाने के लिए क्रॉन जॉब सेट करता हूं। (crontab -e और * * * * * / path / to / job का उपयोग करें) जिस तरह से आप बस फाइलों को संपादित कर सकते हैं और प्रत्येक मिनट उनका परीक्षण किया जाएगा। इसके अतिरिक्त, आप लॉक फ़ाइल को स्पर्श करके क्रोनजोब को रोक सकते हैं।

    #!/bin/sh
    if [ -e /tmp/cronlock ]
    then
        echo "cronjob locked"
        exit 1
    fi

    touch /tmp/cronlock
    <...do your regular cron here ....>
    rm -f /tmp/cronlock

4
आप flock(1)शेल से भी उपयोग कर सकते हैं ; देखते हैं man 1 flock। इस तरह के उपयोग के लिए काफी आसान है क्योंकि यह स्वचालित अवरोधन प्रदान करता है।
क्रेग रिंगर

5

इसे लगाने के बारे में क्या cron.hourly, प्रति घंटा क्रॉन नौकरियों के अगले भाग तक इंतजार करना, फिर इसे निकालना? जो इसे एक घंटे के भीतर और क्रोन वातावरण में एक बार चलाएगा। आप चला भी सकते हैं ./your_script, लेकिन क्रोन के तहत ऐसा वातावरण नहीं होगा।


यह बहुत ही कम @ Cort3z के उत्तर के समान है, कम विस्तार के साथ
jcollum

5

इन उत्तरों में से कोई भी मेरी विशिष्ट स्थिति के अनुकूल नहीं है, जो यह था कि मैं एक विशिष्ट क्रोन नौकरी को चलाना चाहता था, बस एक बार, और इसे तुरंत चलाएं।

मैं एक उबंटू सर्वर पर हूं, और मैं अपने क्रॉन जॉब्स को सेटअप करने के लिए cPanel का उपयोग करता हूं।

मैंने बस अपनी वर्तमान सेटिंग्स लिखी, और फिर उन्हें अब से एक मिनट संपादित किया। जब मैंने एक और बग तय किया, तो मैंने इसे अभी से एक मिनट के लिए फिर से संपादित किया। और जब मैं पूरा हो गया था, तो मैं सेटिंग्स को वापस रीसेट कर देता हूं कि वे पहले कैसे थे।

उदाहरण: अभी ४:३४ बजे है, इसलिए मैंने ३५ १६ * * * डाल दिया, इसके लिए १६:३५ बजे चलेंगे।

यह एक आकर्षण की तरह काम करता था, और मुझे जो सबसे ज्यादा इंतजार करना पड़ता था वह एक मिनट से थोड़ा कम था।

मुझे लगा कि यह कुछ अन्य उत्तरों की तुलना में बेहतर विकल्प था क्योंकि मैं अपने सभी साप्ताहिक क्रोन नहीं चलाना चाहता था, और मैं यह नहीं चाहता था कि नौकरी हर मिनट चले। इसे फिर से परीक्षण करने के लिए तैयार होने से पहले जो भी मुद्दे थे, उन्हें ठीक करने में मुझे कुछ मिनट लगते हैं। उम्मीद है कि यह किसी की मदद करता है।


आप "सिर्फ एक बार, और इसे तुरंत चलाने" के लिए क्रोन का उपयोग क्यों करेंगे? ऐसा लगता है कि आप सीधे स्क्रिप्ट चलाने से बेहतर होंगे।
इयान हंटर

4

इसके अलावा आप भी उपयोग कर सकते हैं:

http://pypi.python.org/pypi/cronwrap

सफलता या विफलता पर आपको एक ईमेल भेजने के लिए अपने क्रोन को लपेटने के लिए।


10
क्या क्रॉन निष्पादन के बाद स्क्रिप्ट से पहले से ईमेल और आउटपुट नहीं करता है?
एरिक

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

3

जो समाधान मैं उपयोग कर रहा हूं वह इस प्रकार है:

  1. क्रस्टैब को संपादित करें (कमांड का उपयोग करें: crontab -e) जितनी बार आवश्यक हो उतनी बार काम चलाने के लिए (हर 1 मिनट या 5 मिनट)
  2. शेल स्क्रिप्ट को संशोधित करें जो आउटपुट को कुछ फ़ाइल में प्रिंट करने के लिए क्रोन का उपयोग करके निष्पादित किया जाना चाहिए (उदाहरण के लिए: इको "वर्किंग फाइन" >>>.
    txt)
  3. कमांड का उपयोग करके output.txt फ़ाइल की जाँच करें: tail -f output.txt, जो इस फ़ाइल में नवीनतम परिवर्धन प्रिंट करेगा, और इस प्रकार आप स्क्रिप्ट के निष्पादन को ट्रैक कर सकते हैं

2

मैं आम तौर पर इस तरह से बनाई गई नौकरी चलाकर परीक्षा देता हूं:

ऐसा करने के लिए दो टर्मिनलों का उपयोग करना आसान है।

नौकरी चलाएं:

#./jobname.sh

के लिए जाओ:

#/var/log and run 

निम्नलिखित चलाएँ:

#tailf /var/log/cron

यह मुझे वास्तविक समय में क्रोन लॉग अपडेट देखने की अनुमति देता है। आप इसे चलाने के बाद लॉग की समीक्षा भी कर सकते हैं, मैं वास्तविक समय में देखना पसंद करता हूं।

यहाँ एक सरल क्रोन नौकरी का उदाहरण दिया गया है। एक यम अद्यतन चल रहा है ...

#!/bin/bash
YUM=/usr/bin/yum
$YUM -y -R 120 -d 0 -e 0 update yum
$YUM -y -R 10 -e 0 -d 0 update

यहाँ ब्रेकडाउन है:

पहले कमांड खुद yum को अपडेट करेगा और बाद में सिस्टम अपडेट को लागू करेगा।

-R 120: सेट करता है कि यम एक कमांड करने से पहले कितना समय इंतजार करेगा

-e 0: त्रुटि स्तर को 0 (सीमा 0 - 10) सेट करता है। 0 का मतलब केवल महत्वपूर्ण त्रुटियों को प्रिंट करना है जिसके बारे में आपको बताया जाना चाहिए।

-d 0: डिबगिंग लेवल को 0 पर सेट करता है - प्रिंट की गई चीजों की मात्रा को ऊपर या नीचे करता है। (रेंज: 0 - 10)।

-य: हाँ मान लें; यह मान लें कि किसी भी प्रश्न का उत्तर जो पूछा जाएगा, वह हां है

मैंने क्रॉन जॉब का निर्माण करने के बाद अपना काम निष्पादन योग्य बनाने के लिए नीचे की कमांड चलाई।

#chmod +x /etc/cron.daily/jobname.sh 

उम्मीद है कि यह मदद करता है, डोरलैक


2
sudo run-parts --test /var/spool/cron/crontabs/

उस crontabs/निर्देशिका में फ़ाइलों को स्वामी - ऑक्टल द्वारा निष्पादित करने की आवश्यकता होती है700

स्रोत: man cronऔर NNRoothएस


5
दो टाँगे। पहला: चीजों को चलाने के लिए जैसा कि एक अलग वातावरण (परिभाषित चर) का उपयोग करता है। तो आपके क्रॉस्टैब में कीड़े 'सुडो' के रूप में निष्पादित होने पर काम कर सकते हैं, लेकिन 'रूट' (और इसके विपरीत) निष्पादित होने पर काम नहीं करेंगे। दूसरा: 'मैन क्रोन' मुझे यह जानकारी नहीं दिखाता है (ठीक है, मेरा आदमी डिबियन-विशिष्ट प्रतीत होता है) ... 'मैन रन-पार्ट्स' का कहना है कि - यह स्क्रिप्ट नहीं चलाता है, लेकिन केवल नामों को छापता है उन्हें। इसलिए लिपियों का परीक्षण भी नहीं किया जाता है। एक मामूली बात: 'स्वामी द्वारा निष्पादित': जहाँ तक मुझे पता है, क्रोनोजर को केवल जड़ के रूप में निष्पादित किया जाता है।
एलेक्स

-1

मैं Webmin का उपयोग कर रहा हूं क्योंकि इसकी उत्पादकता रत्न किसी के लिए है जो कमांड लाइन प्रशासन को थोड़ा कठिन और अभेद्य पाता है।

"सिस्टम> शेड्यूल क्रोन जॉब्स> एडिट क्रोन जॉब" वेब इंटरफेस में "सेव एंड रन नाउ" बटन है।

यह कमांड का आउटपुट दिखाता है और ठीक वैसा ही है जैसा मुझे चाहिए था।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.