Je! Kwa nini maandishi ya crontab hayafanyi kazi?


Nenda kwa jibu lililokubaliwa


Mara nyingi, crontab maandishi hayatekelezwi kwa ratiba au kama inavyotarajiwa. Kuna sababu nyingi za kwamba:

  1. maoni mabaya ya crontab
  2. shida ya ruhusa
  3. Viwango vya mazingira

Wiki hii ya jamii inakusudia kuongeza sababu za juu za crontab hati kutekelezwa kama inavyotarajiwa. Andika kila sababu kwa jibu tofauti.

Tafadhali ni pamoja na sababu moja kwa jibu - maelezo juu ya kwanini haijatekelezwa - na urekebishe (es) kwa sababu hiyo moja.

Tafadhali andika tu maswala maalum ya cron, mfano amri zinazotekelezwa kama inavyotarajiwa kutoka kwa ganda lakini nitafanya makosa na cron.


534









Idadi ya majibu: 30


Mazingira tofauti

Cron hupita seti ndogo ya mazingira ya kazi zako. Ili kuona tofauti, ongeza kazi ya dummy kama hii:

* * * * * * env> /tmp/env.output

Subiri /tmp/env.output kuundwa, halafu ondoa kazi tena. Sasa linganisha yaliyomo /tmp/env.output na pato la env kukimbia kwenye terminal yako ya kawaida.

"Getcha" ya kawaida hapa ni tofauti ya PATH mazingira kuwa tofauti. Labda hati yako ya maandishi hutumia amri somecommand inayopatikana /opt/someApp/bin , ambayo umeongeza PATH ndani /etc/environment ? cron inapuuza PATH kutoka kwa faili hiyo, kwa hivyo runnning somecommand kutoka hati yako itashindwa wakati utafanywa na cron, lakini fanya kazi wakati unasimamiwa kwenye terminal. Inastahili kuzingatia kwamba vigezo kutoka /etc/environment vitapitishwa kwa kazi za cron, sio tu vigeugeu vya cron huweka yenyewe, kama vile PATH .

Ili kuzunguka hayo, weka tangulizi yako mwenyewe PATH juu ya hati. Mazai

 #!/bin/bash
PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

# rest of script follows
 

Wengine wanapendelea kutumia njia kabisa kwa amri zote badala yake. Ninapendekeza dhidi ya hiyo. Fikiria kinachotokea ikiwa unataka kuendesha hati yako kwenye mfumo tofauti, na kwenye mfumo huo, amri iko /opt/someAppv2.2/bin badala yake. Utalazimika kupitia maandishi yote ukibadilisha /opt/someApp/bin na /opt/someAppv2.2/bin badala ya kufanya hariri ndogo tu kwenye safu ya kwanza ya hati.

Unaweza pia kuweka kutofautisha kwa PATH kwenye faili ya crontab, ambayo itatumika kwa kazi zote za cron. Mazai

 PATH=/opt/someApp/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

15 1 * * * backupscript --incremental /home /root
 

512



Getcha yangu ya juu: Ikiwa utasahau kuongeza laini mpya mwishoni mwa crontab faili. Kwa maneno mengine, faili ya crontab inapaswa kumaliza na mstari tupu.

Hapa chini kuna sehemu inayofaa katika kurasa za wanaume kwa toleo hili ( man crontab kisha ruka hadi mwisho):

    Although cron requires that each entry in a crontab end  in  a  newline
   character,  neither the crontab command nor the cron daemon will detect
   this error. Instead, the crontab will appear to load normally. However,
   the  command  will  never  run.  The best choice is to ensure that your
   crontab has a blank line at the end.

   4th Berkeley Distribution      29 December 1993               CRONTAB(1)
 

341



Croni daemon haifanyi kazi. Kwa kweli niligundua na hii miezi kadhaa iliyopita.

Aina:

 pgrep cron 
 

Ikiwa hauoni nambari, basi cron haifanyi kazi. sudo /etc/init.d/cron start inaweza kutumika kuanza cron.

BONYEZA: Badala ya kuvutia maandishi ya init kupitia /etc/init.d, tumia matumizi ya huduma, kwa mfano

 sudo service cron start
 

BONYEZA: Pia unaweza kutumia systemctl katika Linux ya kisasa, mfano

 sudo systemctl start cron
 

139



Majina ya faili script katika cron.d/ , cron.daily/ , cron.hourly/ , nk, haipaswi kuwa na dot ( . ), vinginevyo kukimbia-sehemu utaruka yao.

Tazama sehemu za kukimbia (8):

    If neither the --lsbsysinit option nor the --regex option is given then
   the names must consist entirely of upper and lower case  letters,  dig‐
   its, underscores, and hyphens.

   If  the  --lsbsysinit  option  is given, then the names must not end in
   .dpkg-old  or .dpkg-dist or .dpkg-new or .dpkg-tmp, and must belong  to
   one  or more of the following namespaces: the LANANA-assigned namespace
   (^[a-z0-9]+$);   the   LSB   hierarchical   and   reserved   namespaces
   (^_?([a-z0-9_.]+-)+[a-z0-9]+$);  and  the  Debian cron script namespace
   (^[a-zA-Z0-9_-]+$).
 

Kwa hivyo, ikiwa unayo hati ya maandishi backup.sh , analyze-logs.pl katika cron.daily/ saraka, ungependa kuondoa majina ya kiendelezi.


92



Katika mazingira mengi cron hufanya amri ya kutumia sh , wakati watu wengi wanadhani itatumia bash .

Mapendekezo ya kujaribu au kurekebisha hii kwa amri isiyoshindwa:

  • Jaribu kuendesha agizo sh ili uone ikiwa inafanya kazi:

     sh -c "mycommand"
     
  • Funga amri katika skuli ya bash ili kuhakikisha kuwa inaingia katika bash:

     bash -c "mybashcommand"
     
  • Mwambie cron kutekeleza amri zote katika bash kwa kuweka ganda juu ya ukali wako:

     SHELL=/bin/bash
     
  • Ikiwa amri ni hati, hakikisha hati inayo na shebang:

     #!/bin/bash
     

68



Nilikuwa na maswala kadhaa na maeneo ya wakati. Cron alikuwa akiendesha na eneo la wakati mpya wa ufungaji. Suluhisho lilikuwa kuanza tena cron:

 sudo service cron restart
 

41



Njia kabisa inapaswa kutumika kwa hati:

Kwa mfano, /bin/grep inapaswa kutumiwa badala ya grep :

 # m h  dom mon dow   command
0 0 *  *  *  /bin/grep ERROR /home/adam/run.log &> /tmp/errors
 

Badala ya:

 # m h  dom mon dow   command
0 0 *  *  *  grep ERROR /home/adam/run.log &> /tmp/errors
 

Hii ni hila sana, kwa sababu amri hiyo hiyo itafanya kazi wakati wa kunyongwa kutoka kwa ganda. Sababu ni kwamba cron haina PATH mazingira sawa ya mtumiaji.


36



Ikiwa amri yako ya crontab ina % ishara ndani yake, cron inajaribu kufasiri. Kwa hivyo ikiwa ulikuwa unatumia amri yoyote iliyo na % hiyo (kama vile muundo wa muundo wa amri ya tarehe) utahitajika kuitoroka.

Hiyo na nyingine nzuri hapa:
http://www.pantz.org/software/cron/croninfo.html


33



Cron anaita hati ambayo haiwezi kutekelezwa.

Kwa kuendesha chmod +x /path/to/scrip maandishi kunaweza kutekelezeka na inapaswa kutatua suala hili.


25



Inawezekana pia kwamba nywila ya mtumiaji imepitwa na wakati. Hata nywila ya mizizi inaweza kuisha. Unaweza tail -f /var/log/cron.log na utaona cron ikishindwa na nywila kumalizika muda wake. Unaweza kuweka nywila kamwe kuisha kwa kufanya hivi: passwd -x -1 <username>

Katika mifumo mingine (Debian, Ubuntu) magogo ya cron hayawezeshwa na default. Katika /etc/rsyslog.conf au /etc/rsyslog.d/50-default.conf mstari:

 # cron.*                          /var/log/cron.log
 

inapaswa kuhaririwa sudo nano /etc/rsyslog.conf ))

 cron.*                          /var/log/cron.log
 

Baada ya hayo, unahitaji kuanza tena rsyslog kupitia

 /etc/init.d/rsyslog restart
 

au

 service rsyslog restart 
 

Chanzo: Wezesha ukataji miti kwenye Debian Linux

Katika mifumo mingine (Ubuntu) faili tofauti ya ukataji wa cron haijawezeshwa na default, lakini magogo yanayohusiana na cron yanaonekana kwenye faili ya syslog. Mtu anaweza kutumia

 cat /var/log/syslog | grep cron -i
 

kutazama ujumbe unaohusiana na cron.


24



Ikiwa cronjob yako inavutia programu-za GUI, unahitaji kuwaambia ni TAFUTA ipi inapaswa kutumia.

Mfano: Uzinduzi wa Firefox na cron.

Nakala yako inapaswa kuwa na export DISPLAY=:0 mahali.


18



Shida za ruhusa ni za kawaida sana, ninaogopa.

Kumbuka kuwa workaround ya kawaida ni kutekeleza kila kitu kwa kutumia ukali wa mizizi, ambayo wakati mwingine ni Idea Mbaya kabisa. Kuweka ruhusa sahihi hakika ni suala lililopuuzwa sana.


15



Ruhusa ya meza ya kinga

Jedwali la cron limekataliwa ikiwa ruhusa yake ni ukosefu wa usalama

 sudo service cron restart
grep -i cron /var/log/syslog|tail -2
2013-02-05T03:47:49.283841+01:00 ubuntu cron[49906]: (user) INSECURE MODE (mode 0600 expected) (crontabs/user)
 

Shida hutatuliwa na

 # correct permission
sudo chmod 600 /var/spool/cron/crontabs/user
# signal crond to reload the file
sudo touch /var/spool/cron/crontabs
 

14



Hati ni nyeti ya eneo. Hii inahusiana na kila wakati kutumia njia kabisa kwenye hati, lakini sio sawa. Kazi yako ya cron inaweza kuhitaji cd saraka fulani kabla ya kukimbia, kwa mfano kazi ya kutafuta tafuta ya Reli inaweza kuhitaji kuwa kwenye mzizi wa programu kwa Rake kupata kazi sahihi, bila kutaja usanidi unaofaa wa hifadhidata.

Kwa hivyo kuingia kwa crontab

23 3 * * * /usr/bin/rake db:session_purge RAILS_ENV=production

itakuwa bora kama

23 3 * * * cd / var / www / uzalishaji / sasa && / usr / bin / tafuta db: session_purge RAILS_ENV = uzalishaji

Au, kuweka kiingilio cha crontab rahisi na kidogo brittle:

23 3 * * * /home/<user>/scripts/session-purge.sh

na nambari ifuatayo katika /home/<user>/scripts/session-purge.sh :

cd / var / www / uzalishaji / sasa
/ usr / bin / tafuta db: session_purge RAILS_ENV = uzalishaji

12



Vipimo vya Crontab ambavyo vilifanya kazi huko nyuma vinaweza kuvunja wakati kuhamishwa kutoka faili moja ya crontab kwenda nyingine. Wakati mwingine sababu ni kwamba umehamisha programu kutoka kwa faili ya mfumo wa crontab kwenda kwa faili ya crontab ya mtumiaji au kinyume chake.

Fomati ya uainishaji wa kazi ya cron inatofautiana kati ya faili za watumiaji wa crontab (/ var / spool / cron / username au / var / spool / cron / crontabs / username) na crontabs system ( /etc/crontab na faili in /etc/cron.d ).

Crontabs za mfumo zina mtumiaji wa ziada wa shamba kabla ya agizo la kukimbia.

Hii itasababisha makosa kusema vitu kama george; command not found wakati unapoondoa amri kutoka /etc/crontab au faili /etc/cron.d ndani ya faili ya crontab ya mtumiaji.

Kinyume chake, cron itatoa makosa kama /usr/bin/restartxyz is not a valid username au sawa wakati mabadiliko yanatokea.


11



Nakala ya cron ni kuvuta amri na chaguo la -

Nilikuwa na maandishi ya maandishi ya nipungufu juu yangu kwa sababu nilikuwa kwenye maandishi wakati wa kuchapa maandishi na nilijumuisha chaguo - -

 #!/bin/bash
some commands
tar cvfz /my/archive/file.tar.gz /my/shared/directory
come more commands
 

Maandishi yalikuwa sawa wakati wa kutekeleza kutoka kwa ganda, lakini ilishindikana wakati wa kukimbia kutoka kwa crontab kwa sababu pato la kitenzi linapita wakati wa kukimbia kutoka kwa ganda, lakini hakuna mahali linapotokea kutoka kwa crontab. Rahisi kurekebisha kuondoa 'v':

 #!/bin/bash
some commands
tar cfz /my/archive/file.tar.gz /my/shared/directory
some more commands
 

10



Sababu ya mara kwa mara nimeona cron ikishindwa katika ratiba iliyosemwa vibaya. Inachukua mazoezi kutaja kazi iliyopangwa saa 11:15 jioni kama 15 23 * * * badala ya * * 11 15 * au 11 15 * * * . Siku ya juma kwa kazi baada ya usiku wa manane pia inachanganyikiwa MF ni 2-6 baada ya usiku wa manane, sivyo 1-5 . Tarehe maalum kawaida ni shida kwani tunazitumia mara chache * * 3 1 * sio Machi 3. Ikiwa hauna hakika, angalia ratiba zako za mkondoni mtandaoni saa https://crontab.guru/ .

Ikiwa kazi yako na majukwaa tofauti kwa kutumia chaguzi ambazo hazijasaidiwa kama vile ilivyo 2/3 kwa wakati wa wakati pia kunaweza kusababisha kutofaulu. Hii ni chaguo muhimu sana lakini haipatikani kwa ulimwengu. Mimi pia kuendeshwa kwenye masuala na orodha kama 1-5 au 1,3,5 .

Kutumia njia ambazo hazina sifa pia kumesababisha shida. Njia default ni kawaida /bin:/usr/bin ili tu viwango vya kawaida vitasimama. Saraka hizi kawaida hazina amri inayotaka. Hii pia inaathiri maandishi kwa kutumia amri zisizo za kiwango. Viwango vingine vya mazingira pia vinaweza kukosa.

Kulipua crontab iliyopo kabisa kumenisababisha shida. Mimi sasa mzigo kutoka nakala nakala. Hii inaweza kulipwa kutoka kwa crontab iliyopo ukitumia crontab -l ikiwa itaboreshwa. Ninahifadhi nakala ya crontab in ~ / bin. Imechapishwa kote na kuishia na mstari # EOF . Hii hupakia kila siku kutoka kwa kiingilio cha crontab kama:

#! / usr / bin / crontab
# Pakia tena usumbufu huu
#
54 12 * * * $ {HOME} / bin / crontab

Amri ya kupakia upya hapo juu hutegemea crontab inayoweza kutekelezwa na njia ya bang inayoendesha crontab. Mifumo mingine inahitaji crontab inayoendesha katika amri na kutaja faili. Ikiwa saraka imeshirikiwa kwa mtandao, basi mimi hutumia crontab.$(hostname) kama jina la faili. Mwishowe hii itarekebisha kesi ambapo kubandika vibaya kumepakiwa kwenye seva isiyofaa.

Kutumia faili kunatoa nakala ya kile crontab inapaswa kuwa, na inaruhusu mabadiliko ya muda (wakati pekee ninayotumia crontab -e ) kurudishwa kiatomati. Kuna vichwa vinavyopatikana ambavyo husaidia kwa kupata vigezo vya ratiba kulia. Nimewaongeza wakati watumiaji wasio na uzoefu wangekuwa wakibadilisha crontab.

Mara chache, nimeingia kwenye amri ambazo zinahitaji pembejeo za watumiaji. Hizi hushindwa chini ya usumbufu, ingawa baadhi itafanya kazi na uelekezaji wa pembejeo.


10



Ikiwa una amri kama hii:

 * * * * * /path/to/script >> /tmp/output
 

na haifanyi kazi na hauwezi kuona mazao yoyote, inaweza kumaanisha kuwa cron haifanyi kazi. Hati inaweza kuvunjika na matokeo yatapita kwa stderr ambayo hayapitiliwi kwa / tmp / pato. Angalia hii sio hii, kwa kukamata pato hili pia:

 * * * * * /path/to/script >> /tmp/output 2>&1
 

kuona kama hii inakusaidia kupata suala lako.


8



Ikiwa unapata akaunti kupitia funguo za SSH inawezekana kuingia kwenye akaunti lakini usigundue kuwa nywila kwenye akaunti imefungwa (kwa mfano kutokana na kumalizika kazi au jaribio batili la nywila)

Ikiwa mfumo unatumia PAM na akaunti imefungwa, hii inaweza kuzuia ujanja wake kukimbia. (Nimejaribu hii kwa Solaris, lakini sio kwa Ubuntu)

Unaweza kupata ujumbe kama huu katika / var / adm / meseji:

Oktoba 24 07:51:00 mybox cron [29024]: [ID 731128 Author.notice] pam_unix_account: cron kujaribu kuhalalisha myuser wa akaunti iliyofungwa kutoka kwa mwenyeji wa ndani
Oktoba 24 07:52:00 mybox cron [29063]: [ID 731128 Author.notice] pam_unix_account: cron kujaribu kuhalalisha myuser wa akaunti iliyofungwa kutoka kwa mwenyeji wa ndani
Oktoba 24 07:53:00 mybox cron [29098]: [ID 731128 Author.notice] pam_unix_account: cron kujaribu kuhalalisha myuser wa akaunti iliyofungwa kutoka kwa mwenyeji wa ndani
Oktoba 24 07:54:00 mybox cron [29527]: [ID 731128 Author.notice] pam_unix_account: cron kujaribu kuhakiki myuser akaunti iliyofungwa kutoka kwa mwenyeji wa ndani

Unachohitaji kufanya ni kukimbia:

# passwd -u <USERNAME>

kama mzizi kufungua akaunti, na crontab inapaswa kufanya kazi tena.


7



=== tahadhari ya Docker ===

Ikiwa unatumia kizimbani,

Nadhani ni sawa kuongeza kuwa sikuweza kusimamia kutengeneza cron nyuma.

Kuendesha kazi ya cron ndani ya chombo, nilitumia msimamizi na nikakimbia cron -f , pamoja na mchakato mwingine.

Hariri: Suala lingine - pia sikuweza kuifanya ifanye kazi wakati wa kuendesha kontena na mtandao wa HOST. Tazama suala hili hapa pia: https://github.com/phusion/baseimage-docker/issues/144


3



Nilikuwa nikiandika hati ya kufunga ya ganda inayounda hati nyingine ya kusafisha data ya manunuzi ya zamani kutoka kwa hifadhidata. Kama sehemu ya kazi ilibidi usanidi cron kazi ya kila siku kuendesha kwa wakati wa kiholela, wakati mzigo wa database ulikuwa chini.

mycronjob Niliunda faili na ratiba ya cron, jina la mtumiaji na amri na kuiga kwa /etc/cron.d saraka. Wangu wawili

  1. mycronjob faili ililazimikiwa kumilikiwa na mizizi ili kuendeshwa
  2. Ilinibidi kuweka ruhusa ya faili kwa 644 - 664 haingeenda.

Shida ya ruhusa itaonekana /var/log/syslog kama kitu sawa na:

 Apr 24 18:30:01 ip-11-22-33-44 cron[40980]: (*system*) INSECURE MODE (group/other writable) (/etc/crontab)
Apr 24 18:30:01 ip-11-22-33-44 cron[40980]: (*system*) INSECURE MODE (group/other writable) (/etc/cron.d/user)
 

Mstari wa kwanza unarejelea /etc/crontab faili na baadaye kwa faili niliyoweka chini /etc/cront.d .


3



Mistari iliyoandikwa kwa njia crontab haelewi. Inahitaji kuandikwa kwa usahihi. Hapa kuna CrontabHowTo .


2



Cron daemon inaweza kuwa inafanya kazi, lakini sio kweli inafanya kazi. Jaribu kuanza tena cron:

 sudo /etc/init.d/cron restart
 

2



Kuandika kwa cron kupitia "crontab -e" na hoja ya jina la mtumiaji kwenye mstari. Nimeona mifano ya watumiaji (au sysadmins) wakiandika maandishi yao ya ganda na hawaelewi kwa nini hawajijeshi. Hoja ya "mtumiaji" inapatikana katika / nk / crontab, lakini sio faili zilizoainishwa na mtumiaji. kwa hivyo, kwa mfano, faili yako ya kibinafsi itakuwa kitu kama:

 # m h dom mon dow command

* * */2  *   *  /some/shell/script
 

ambapo / nk / crontab itakuwa:

 # m h dom mon dow user   command

* * */2  *   *  jdoe   /some/shell/script
 

Kwa hivyo, kwa nini unaweza kufanya mwisho? Kweli, kulingana na jinsi unataka kuweka ruhusa yako, hii inaweza kushawishiwa sana. Nimeandika maandishi ili kugeuza kazi kwa watumiaji ambao hawaelewi maumbile, au hawataki kusumbua na shida. Kwa kuweka ruhusa kwa --x------ , naweza kufanya hati ifanyike bila wao kuweza kusoma (na labda kuibadilisha kwa bahati). Walakini, naweza kutaka kutekeleza agizo hili na wengine kadhaa kutoka faili moja (na hivyo kuifanya iwe rahisi kutunza) lakini hakikisha kuwa pato la faili limepewa mmiliki sahihi. Kufanya hivyo (angalau katika Ubuntu 10.10) kuvunja kutokuwa na uwezo wa kusoma faili vile vile na kutekeleza, pamoja na suala lililotajwa hapo awali na kuweka vipindi katika / nk / crontab (ambayo, kwa raha ya kutosha, husababisha kosa wakati wa kupita crontab -e ) .

Kama mfano, nimeona matukio ya sudo crontab -e kutumika kuendesha hati na ruhusa ya mizizi, na sambamba chown username file_output katika hati ya ganda. Sloppy, lakini inafanya kazi. IMHO, Chaguo nzuri zaidi ni kuiweka /etc/crontab na jina la mtumiaji lililotangazwa na ruhusa sahihi, kwa hivyo file_output huenda mahali sahihi na mmiliki.


2



Kuunda kile Aaron Peart alichokisema juu ya modi ya kitenzi, wakati mwingine hati zisizo katika muundo wa kitenzi zitaanzisha lakini hazitamaliza ikiwa tabia ya chaguo-msingi ya amri iliyojumuishwa ni kutoa mstari au zaidi kwenye skrini mara tu kuanza. Kwa mfano, niliandika nakala ya nakala rudufu ya intranet yetu ambayo ilitumia curl, matumizi ambayo hupakua au kupakia faili kwenye seva za mbali, na ni sawa ikiwa unaweza kupata faili za mbali tu kupitia HTTP. Kutumia 'curl http://something.com/somefile.xls ' ilikuwa ikisababisha hati niliyoandika kutundika na kamwe sikamilisha kwa sababu inamwagika laini mpya ikifuatiwa na mstari wa maendeleo. Ilinibidi nitumie bendera ya kimya (-s) kuiambia isitoe habari yoyote, na kuandika kwa msimbo wangu mwenyewe kushughulikia ikiwa faili ilishindwa kupakua.


2



Ingawa unaweza kufafanua vigeugeu vya mazingira katika usumbufu wako, hauko kwenye hati ya ganda. Kwa hivyo ujenzi kama ufuatao hautafanya kazi:

 SOME_DIR=/var/log
MY_LOG_FILE=${SOME_LOG}/some_file.log

BIN_DIR=/usr/local/bin
MY_EXE=${BIN_DIR}/some_executable_file

0 10 * * * ${MY_EXE} some_param >> ${MY_LOG_FILE}
 

Hii ni kwa sababu vigezo havitafsiriwi katika kihalali: maadili yote huchukuliwa. Na hii ni sawa ikiwa utaachilia mabano. Kwa hivyo maagizo yako hayatatekelezwa, na faili zako za kumbukumbu hazitaandikwa ...

Badala yake lazima ufafanue mazingira yako anuwai zote moja kwa moja:

 SOME_DIR=/var/log
MY_LOG_FILE=/var/log/some_file.log

BIN_DIR=/usr/local/bin
MY_EXE=/usr/local/bin/some_executable_file

0 10 * * * ${MY_EXE} some_param >> ${MY_LOG_FILE}
 

2



Wakati kazi inaendeshwa ndani ya cron, stdin imefungwa. Programu ambazo hutenda tofauti kulingana na ikiwa stdin inapatikana au la watafanya tofauti kati ya kikao cha ganda na kwenye cron.

Mfano ni mpango wa goaccess kuchambua faili za logi za wavuti. Hii haifanyi kazi katika cron:

 goaccess -a -f /var/log/nginx/access.log > output.html
 

na goaccess inaonyesha ukurasa wa msaada badala ya kuunda ripoti hiyo. Katika ganda hii inaweza kuzaliwa tena na

 goaccess -a -f /var/log/nginx/access.log > output.html < /dev/null
 

Kurekebisha goaccess ni kuifanya isome logi kutoka kwa stdin badala ya kusoma kutoka kwa faili, kwa hivyo suluhisho ni kubadili kiingilio cha crontab kwa

 cat /var/log/nginx/access.log | goaccess -a > output.html
 

2



Katika kesi yangu cron na crontab walikuwa na wamiliki tofauti.

SI ya kufanya kazi nilikuwa na hii:

 [email protected] ~ $ ps -ef | grep cron | grep -v grep
User    2940    7284 pty1     19:58:41 /usr/bin/crontab
SYSTEM   11292     636 ?        22:14:15 /usr/sbin/cro 
 

Kimsingi ilinibidi kukimbia cron-kon na kujibu maswali kwa usahihi. Kuna uhakika ambapo nilihitajika kuweka nenosiri langu la mtumiaji la Win7 kwa akaunti yangu ya 'Mtumiaji'. Kuanzia kusoma nilifanya, inaonekana kama hii ni suala linaloweza kutokea la usalama lakini mimi ndiye msimamizi pekee kwenye mtandao mmoja wa nyumbani kwa hivyo niliamua ilikuwa sawa.

Hapa kuna mlolongo wa amri ambao ulinifanya niende:

 [email protected] ~ $ cron-config
The cron daemon can run as a service or as a job. The latter is not recommended.
Cron is already installed as a service under account LocalSystem.
Do you want to remove or reinstall it? (yes/no) yes
OK. The cron service was removed.

Do you want to install the cron daemon as a service? (yes/no) yes
Enter the value of CYGWIN for the daemon: [ ] ntsec

You must decide under what account the cron daemon will run.
If you are the only user on this machine, the daemon can run as yourself.
   This gives access to all network drives but only allows you as user.
To run multiple users, cron must change user context without knowing
  the passwords. There are three methods to do that, as explained in
  http://cygwin.com/cygwin-ug-net/ntsec.html#ntsec-nopasswd1
If all the cron users have executed "passwd -R" (see man passwd),
  which provides access to network drives, or if you are using the
  cyglsa package, then cron should run under the local system account.
Otherwise you need to have or to create a privileged account.
  This script will help you do so.
Do you want the cron daemon to run as yourself? (yes/no) no

Were the passwords of all cron users saved with "passwd -R", or
are you using the cyglsa package ? (yes/no) no

Finding or creating a privileged user.
The following accounts were found: 'cyg_server' .
This script plans to use account cyg_server.
Do you want to use another privileged account name? (yes/no) yes
Enter the other name: User

Reenter: User


Account User already exists. Checking its privileges.
INFO: User is a valid privileged account.
INFO: The cygwin user name for account User is User.

Please enter the password for user 'User':
Reenter:
Running cron_diagnose ...
... no problem found.

Do you want to start the cron daemon as a service now? (yes/no) yes
OK. The cron daemon is now running.

In case of problem, examine the log file for cron,
/var/log/cron.log, and the Windows event log (using /usr/bin/cronevents)
for information about the problem cron is having.

Examine also any cron.log file in the HOME directory
(or the file specified in MAILTO) and cron related files in /tmp.

If you cannot fix the problem, then report it to [email protected]
Please run the script /usr/bin/cronbug and ATTACH its output
(the file cronbug.txt) to your e-mail.

WARNING: PATH may be set differently under cron than in interactive shells.
         Names such as "find" and "date" may refer to Windows programs.


[email protected] ~ $ ps -ef | grep cron | grep -v grep
    User    2944   11780 ?        03:31:10 /usr/sbin/cron
    User    2940    7284 pty1     19:58:41 /usr/bin/crontab

[email protected] ~ $
 

2



Kwenye seva zangu za RHEL7, kazi za mizizi ya cron zingeenda, lakini kazi za watumiaji hazingefanya. Niligundua kuwa bila saraka ya nyumba, kazi hazitafanya (lakini utaona makosa mazuri katika / var / logi / cron). Nilipounda saraka ya nyumba, shida ilitatuliwa.


2



Ikiwa umehariri faili yako ya crontab kutumia hariri ya windows (kupitia samba au kitu) na ikibadilishwa orodha mpya na \ n \ r au tu \ r, cron haitaenda.

Pia, ikiwa unatumia /etc/cron.d/* na moja ya faili hizo ina \ r ndani yake, cron itapita kupitia faili na ikasimama wakati inagonga faili mbaya. Sijui kama hiyo ndio shida?

Tumia:

 od -c /etc/cron.d/* | grep \r
 

2



Machapisho yanayohusiana


Je! Kwa nini Apache yangu haifanyi kazi baada ya kuboresha kuwa Ubuntu 14.04?

Je! Ni kwanini wakati mwingine kufanya kazi kukausha haifanyi kazi katika gongo-terminal?

Kwa nini amri ya pssh haifanyi kazi?

Kwa nini ctrl + v haifanyi kazi katika terminal [duplicate]

Je! Ni kwanini baadhi ya programu za kurekodi / kukamata skrini (au vipengee vya programu) hazifanyi kazi baada ya kusasisha hadi Ubuntu 17.10?

CTRL + ALT + L na CTRL + ALT + DEL haifanyi kazi ubuntu 12.04?

Kwa nini Mount.cif haifanyi kazi katika fstab tena baada ya kusasisha kutoka 16.04 hadi 18.04?

njia za mkato za alt katika pycharm haifanyi kazi Ubuntu 16.04

Je! Ni kwanini baadhi ya programu za kurekodi / kukamata skrini (au vipengee vya programu) hazifanyi kazi baada ya kusasisha hadi Ubuntu 17.10?

Kwa nini 'tengeneza gconfig' haifanyi kazi wakati wa kuandaa kernel?

Maswali mengine aliweka tag [cron]


Ninasanikisha vipi faili ya .deb kupitia mstari wa amri?

Haiwezi kufunga saraka ya utawala (/ var / lib / dpkg /) ni mchakato mwingine kuitumia?

Jinsi ya kupata bash au ssh kwenye chombo kinachoendesha katika hali ya chini?

Jinsi ya kusasisha kifurushi kimoja ukitumia apt-kupata?

Je! Ninawezaje kufunga au kuanza upya kutoka kwa terminal?

Ujumbe wa makosa "sudo: haiwezi kusuluhisha mwenyeji (hapana)"

Jinsi ya kuongeza saraka kwenye BARA?

Jinsi ya kuongeza mtumiaji aliyepo kwenye kikundi kilichopo?

Je! Ninawezaje kurekebisha suala langu la locale?

Boti yangu ya kompyuta kwa skrini nyeusi, ni chaguzi gani ambazo ninaweza kurekebisha?