Crontab ස්ක්‍රිප්ට් ක්‍රියා නොකරන්නේ ඇයි?

බොහෝ විට, crontabස්ක්‍රිප්ට් නියමිත වේලාවට හෝ අපේක්ෂිත පරිදි ක්‍රියාත්මක නොවේ. ඒ සඳහා හේතු ගණනාවක් තිබේ:

1. වැරදි ක්‍රොන්ටාබ් අංකනය
2. අවසර ගැටලුව
3. පරිසර විචල්යයන්

මෙම ප්‍රජා විකිය අරමුණු කරන්නේ crontabස්ක්‍රිප්ට් අපේක්ෂිත පරිදි ක්‍රියාත්මක නොකිරීමට ප්‍රධාන හේතු එකතු කිරීමයි . සෑම හේතුවක්ම වෙනම පිළිතුරකින් ලියන්න.

කරුණාකර පිළිතුරකට එක් හේතුවක් ඇතුළත් කරන්න - එය ක්‍රියාත්මක නොවීමට හේතුව පිළිබඳ විස්තර - සහ එම එක් හේතුවක් සඳහා (එස්) නිවැරදි කරන්න.

කරුණාකර ක්‍රෝන්-විශේෂිත ගැටළු පමණක් ලියන්න, උදා: කවචයෙන් අපේක්ෂිත පරිදි ක්‍රියාත්මක වන නමුත් ක්‍රෝන් මඟින් වැරදි ලෙස ක්‍රියාත්මක කරන විධාන.

විවිධ පරිසරය

ක්‍රොන් ඔබේ රැකියා සඳහා අවම පරිසර විචල්‍යයන් සමූහයක් ලබා දෙයි. වෙනස බැලීමට, මේ වගේ ව්‍යාජ රැකියාවක් එක් කරන්න:

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

/tmp/env.outputනිර්මාණය වන තෙක් රැඳී සිටින්න , පසුව කාර්යය නැවත ඉවත් කරන්න. දැන් ඔබේ සාමාන්‍ය පර්යන්තයේ ධාවන /tmp/env.outputප්‍රතිදානය සමඟ අන්තර්ගතය සසඳා බලන්න env.

මෙහි පොදු "ගොචා" යනු PATHපරිසර විචල්‍යය වෙනස් වීමයි. සමහර විට ඔබේ cron වලින් තිර රචනය විධානය භාවිතා somecommandසොයා /opt/someApp/binඔබ එකතු කර ඇත අතර, PATHදී /etc/environment? cron PATHඑම ගොනුවෙන් නොසලකා හරිනු ඇත, එබැවින් somecommandක්‍රෝන් සමඟ ධාවනය වන විට ඔබේ ස්ක්‍රිප්ටයෙන් ධාවනය කිරීම අසාර්ථක වනු ඇත, නමුත් පර්යන්තයක ධාවනය වන විට ක්‍රියා කරයි. විචල්‍යයන් /etc/environmentක්‍රෝන් රැකියා වෙත ලබා දෙන බව සඳහන් කිරීම වටී , විචල්‍යයන් ක්‍රෝන් නිශ්චිතවම සැකසෙන්නේ නැත PATH.

එය මඟහරවා ගැනීම සඳහා, ඔබේම PATHවිචල්‍යය ස්ක්‍රිප්ටයේ ඉහළින්ම සකසන්න . උදා

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

# rest of script follows

සමහරු ඒ වෙනුවට සියලු විධානයන් සඳහා නිරපේක්ෂ මාර්ග භාවිතා කිරීමට කැමැත්තක් දක්වති. ඊට එරෙහිව මම නිර්දේශ කරමි. ඔබේ ස්ක්‍රිප්ට් වෙනත් පද්ධතියක ධාවනය කිරීමට අවශ්‍ය නම් කුමක් සිදුවේද යන්න සලකා බලන්න, එම පද්ධතිය තුළ විධානය ක්‍රියාත්මක වේ /opt/someAppv2.2/bin. ඔබ වෙනුවට මුළු තිර රචනය හරහා යන්න ඇති කියලා /opt/someApp/binසමග /opt/someAppv2.2/binපමණක් තිර රචනය මුල් මාර්ගයේ කුඩා සංස්කරණය කරන්නේ වෙනුවට.

ඔබට ක්‍රොන්ටාබ් ගොනුවේ PATH විචල්‍යය සැකසිය හැකි අතර එය සියලුම ක්‍රෝන් රැකියා සඳහා අදාළ වේ. උදා

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

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

මගේ ඉහළ ගොචා: crontabගොනුවේ අවසානයේ නව රේඛාවක් එක් කිරීමට ඔබට අමතක වුවහොත් . වෙනත් වචන වලින් කිවහොත්, crontab ගොනුව හිස් රේඛාවකින් අවසන් විය යුතුය.

මෙම නිකුතුව සඳහා මෑන් පිටුවල අදාළ කොටස පහත දැක්වේ ( man crontabඉන්පසු අවසානය දක්වා මඟ හරින්න):

   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)

ක්‍රෝන් ඩීමන් ක්‍රියාත්මක නොවේ. මම ඇත්තටම මීට මාස කිහිපයකට පෙර මේ ගැන සොයා බැලුවෙමි.

වර්ගය:

pgrep cron 

ඔබ අංකයක් නොපෙනේ නම් (එනම් ක්‍රෝන්ගේ ප්‍රධාන PID), එවිට ක්‍රෝන් ක්‍රියාත්මක නොවේ. sudo /etc/init.d/cron startcron ආරම්භ කිරීමට භාවිතා කළ හැකිය.

සංස්කරණය කරන්න: /etc/init.d හරහා init ස්ක්‍රිප්ට් භාවිතා කරනවා වෙනුවට, සේවා උපයෝගීතාව භාවිතා කරන්න, උදා

sudo service cron start

සංස්කරණය කරන්න: එසේම ඔබට නවීන ලිනක්ස් හි systemctl භාවිතා කළ හැකිය, උදා

sudo systemctl start cron

දී තිර රචනය යන ගොනු නාමය cron.d/, cron.daily/, cron.hourly/, ආදිය, තිතක් අඩංගු නොවිය යුතුය ( .), වෙනත් ආකාරයකින් ක්රියාත්මක-කොටස් ඔවුන් මඟ වනු ඇත.

ධාවන කොටස් බලන්න (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_-]+$).

ඒ නිසා, ඔබ cron වලින් තිර රචනය තිබේ නම් backup.sh, analyze-logs.plදී cron.daily/බහලුම, ඔබ හොඳම දීර්ඝ නම් ඉවත් කිරීමට හොඳයි.

බොහෝ පරිසරවල ක්‍රෝන් භාවිතයෙන් විධාන ක්‍රියාත්මක කරන shඅතර බොහෝ අය එය භාවිතා කරනු ඇතැයි උපකල්පනය කරති bash.

අසමත් විධානයක් සඳහා මෙය පරීක්ෂා කිරීමට හෝ නිවැරදි කිරීමට යෝජනා:

• එය ක්‍රියාත්මක වේදැයි බැලීමට විධානය ක්‍රියාත්මක කිරීමට උත්සාහ කරන්න sh:

  sh -c "mycommand"
  

• විධානය bash subhell එකකින් ඔතා එය bash වලින් ක්‍රියාත්මක වන බවට වග බලා ගන්න:

  bash -c "mybashcommand"
  

• ඔබේ ක්‍රොන්ටාබ් මුදුනේ කවචය සැකසීමෙන් සියලුම විධාන කඩිනමින් ධාවනය කිරීමට ක්‍රොන්ට කියන්න:

  SHELL=/bin/bash
  

• විධානය ස්ක්‍රිප්ට් එකක් නම්, ස්ක්‍රිප්ටයේ ෂෙබාං අඩංගු බවට වග බලා ගන්න:

  #!/bin/bash
  

මට කාල කලාප සමඟ ගැටලු කිහිපයක් තිබුණි. ක්‍රොන් ක්‍රියාත්මක වූයේ නැවුම් ස්ථාපන කාල කලාපය සමඟ ය. විසඳුම වූයේ ක්‍රෝන් නැවත ආරම්භ කිරීමයි:

sudo service cron restart

ස්ක්‍රිප්ට් සඳහා නිරපේක්ෂ මාර්ගය භාවිතා කළ යුතුය:

උදාහරණයක් ලෙස, /bin/grepඒ වෙනුවට භාවිතා කළ යුතුය grep:

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

වෙනුවට:

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

මෙය විශේෂයෙන් උපක්‍රමශීලී ය, මන්ද යත් ෂෙල් එකෙන් ක්‍රියාත්මක වන විට එකම විධානය ක්‍රියාත්මක වන බැවිනි. හේතුව පරිශීලකයාට cronසමාන PATHපරිසර විචල්‍යයක් නොමැති වීමයි.

ඔබේ crontab විධානයෙහි %සංකේතයක් තිබේ නම්, ක්‍රොන් එය අර්ථ නිරූපණය කිරීමට උත්සාහ කරයි. එබැවින් ඔබ එහි කිසියම් විධානයක් භාවිතා කරන්නේ නම් %(දිනය විධානයට ආකෘති පිරිවිතර වැනි) ඔබට එයින් ගැලවීමට අවශ්‍ය වනු ඇත.

එය සහ මෙහි ඇති වෙනත් හොඳ තොරතුරු:
http://www.pantz.org/software/cron/croninfo.html

ක්‍රෝන් ක්‍රියාත්මක කළ නොහැකි පිටපතක් අමතයි.

ධාවනය කිරීමෙන් chmod +x /path/to/script, ස්ක්‍රිප්ට් ක්‍රියාත්මක කළ හැකි අතර මෙය මෙම ගැටළුව විසඳිය යුතුය.

පරිශීලකයාගේ මුරපදය කල් ඉකුත් වී ඇති බවට ද සිතිය හැකිය. මූලයේ මුරපදය පවා කල් ඉකුත් විය හැකිය. ඔබ හැකි tail -f /var/log/cron.logසහ ඔබ cron වලින් මුරපදය අසමත් කල් ඉකුත් දකිනු ඇත. මෙය කිරීමෙන් ඔබට කිසි විටෙකත් කල් ඉකුත් නොවන ලෙස මුරපදය සැකසිය හැකිය:passwd -x -1 <username>

සමහර පද්ධති වල (ඩේබියන්, උබුන්ටු) ක්‍රෝන් සඳහා ලොග් වීම පෙරනිමියෙන් සක්‍රීය නොවේ. දී /etc/rsyslog.conf හෝ /etc/rsyslog.d/50-default.conf රේඛාව:

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

සංස්කරණය කළ යුතුය ( sudo nano /etc/rsyslog.conf) මෙයට නොගැලපේ:

cron.*                          /var/log/cron.log

ඊට පසු, ඔබ rsyslog හරහා නැවත ආරම්භ කළ යුතුය

/etc/init.d/rsyslog restart

හෝ

service rsyslog restart 

මූලාශ්‍රය: ඩේබියන් ලිනක්ස් හි ක්‍රොන්ටාබ් ලොග් වීම සක්‍රීය කරන්න

සමහර පද්ධති වල (උබුන්ටු) ක්‍රෝන් සඳහා වෙනම ලොග් ගොනුවක් පෙරනිමියෙන් සක්‍රීය කර නැත, නමුත් ක්‍රෝන් සම්බන්ධ ල logs ු-සටහන් syslog ගොනුවේ දිස් වේ. යමෙකු භාවිතා කළ හැකිය

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

ක්‍රෝන් ආශ්‍රිත පණිවිඩ බැලීමට.

ඔබගේ ක්‍රොන්ජොබ් විසින් GUI- යෙදුම් ඉල්ලා සිටින්නේ නම්, ඔවුන් භාවිතා කළ යුතු ප්‍රදර්ශනය කුමක්දැයි ඔබ ඔවුන්ට පැවසිය යුතුය.

උදාහරණය: ක්‍රෝන් සමඟ ෆයර්ෆොක්ස් දියත් කිරීම.

ඔබේ ස්ක්‍රිප්ටයේ export DISPLAY=:0කොතැනක හෝ අඩංගු විය යුතුය .

අවසර ගැටළු බහුලව දක්නට ලැබේ, මම බිය වෙමි.

පොදු ක්‍රියාමාර්ගයක් වන්නේ රූට්ගේ ක්‍රොන්ටාබ් භාවිතයෙන් සෑම දෙයක්ම ක්‍රියාත්මක කිරීමයි, එය සමහර විට ඇත්තෙන්ම නරක අදහසකි. නිසි අවසර ලබා දීම අනිවාර්යයෙන්ම බොහෝ දුරට නොසලකා හරින ලද කරුණකි.

අනාරක්ෂිත ක්‍රෝන් මේස අවසරය

ක්‍රෝන් වගුවක් එහි අවසරය අනාරක්ෂිත නම් ප්‍රතික්ෂේප කරනු ලැබේ

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)

සමඟ ගැටළුව විසඳනු ලැබේ

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

ස්ක්‍රිප්ට් ස්ථානය සංවේදී ය. මෙය සැමවිටම ස්ක්‍රිප්ට් එකක නිරපේක්ෂ මාර්ග භාවිතා කිරීම හා සම්බන්ධ නමුත් එය සමාන නොවේ. ඔබේ ක්‍රෝන් කාර්යය cdක්‍රියාත්මක වීමට පෙර නිශ්චිත නාමාවලියකට අවශ්‍ය විය හැකිය , උදා: රේල්ස් යෙදුමක් මත රයික් කාර්යයක් නිවැරදි කාර්යය සොයා ගැනීම සඳහා රේක් සඳහා යෙදුම් මූලයේ තිබිය යුතුය, සුදුසු දත්ත සමුදා වින්‍යාසය සඳහන් නොකිරීම යනාදිය.

ඒ නිසා crontab ඇතුල් වීම

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

වඩා හොඳ වනු ඇත

23 3 * * * cd / var / www / production / current && / usr / bin / rake db: session_purge RAILS_ENV = නිෂ්පාදනය

නැතහොත්, ක්‍රොන්ටාබ් ප්‍රවේශය සරල හා අඩු අස්ථාවර ලෙස තබා ගැනීමට:

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

පහත කේතය සමඟ /home/<user>/scripts/session-purge.sh:

cd / var / www / production / current
/ usr / bin / rake db: session_purge RAILS_ENV = නිෂ්පාදනය

අතීතයේ වැඩ කළ ක්‍රොන්ටාබ් පිරිවිතර එක් ක්‍රොන්ටාබ් ගොනුවක සිට තවත් ගොනුවකට ගෙන යන විට කැඩී යා හැක. සමහර විට හේතුව ඔබ පද්ධති ක්‍රොන්ටාබ් ගොනුවක සිට පරිශීලක ක්‍රොන්ටාබ් ගොනුවකට හෝ අනෙක් අතට මාරු කර තිබීමයි.

ක්‍රෝන් රැකියා පිරිවිතර ආකෘතිය පරිශීලකයින්ගේ ක්‍රොන්ටාබ් ලිපිගොනු (/ var / spool / cron / username හෝ / var / spool / cron / crontabs / username) සහ පද්ධති crontabs ( /etc/crontabසහ ඇති ගොනු /etc/cron.d) අතර වෙනස් වේ.

විධාන ක්‍රියාත්මක කිරීමට පෙර පද්ධති ක්‍රොන්ටාබ් වලට අතිරේක 'පරිශීලකයෙකු' ඇත.

මෙය george; command not foundඔබ විධානයක් පිටතට ගෙන යන විට /etc/crontabහෝ ගොනුවක් /etc/cron.dපරිශීලක ක්‍රොන්ටාබ් ගොනුවකට ගෙන යන විට වැනි දෝෂයන් ඇති කරයි.

අනෙක් අතට, /usr/bin/restartxyz is not a valid usernameආපසු හැරවීම සිදු වූ විට ක්‍රෝන් වැනි හෝ ඊට සමාන දෝෂ ලබා දෙනු ඇත .

cron script යනු --verbose විකල්පය සහිත විධානයක් ක්‍රියාත්මක කිරීමයි

ස්ක්‍රිප්ට් ටයිප් කරන අතරතුර මම ස්වයංක්‍රීය නියමුවෙකු වූ නිසා මට ක්‍රෝන් ස්ක්‍රිප්ට් එකක් අසමත් විය.

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

ෂෙල් එකෙන් ක්‍රියාත්මක වන විට ස්ක්‍රිප්ට් එක හොඳින් ක්‍රියාත්මක වූ නමුත් ක්‍රොන්ටාබ් සිට ධාවනය කිරීමේදී එය අසාර්ථක විය. 'V' ඉවත් කිරීමට පහසු විසඳුමක්:

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

ඔබට මෙවැනි විධානයක් තිබේ නම්:

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

එය ක්‍රියා නොකරන අතර ඔබට කිසිදු ප්‍රතිදානයක් දැකිය නොහැක, එයින් අදහස් කරන්නේ ක්‍රෝන් ක්‍රියා නොකරන බවයි. ස්ක්‍රිප්ට් එක බිඳ දැමිය හැකි අතර ප්‍රතිදානය / tmp / ප්‍රතිදානය වෙත නොපැමිණෙන stderr වෙත යයි. මෙම ප්‍රතිදානය අල්ලා ගැනීමෙන් මෙය එසේ නොවේදැයි පරීක්ෂා කරන්න:

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

මෙය ඔබගේ ගැටලුව හසු කර ගැනීමට උපකාරී වේදැයි බැලීමට.

වැරදියට ප්‍රකාශිත කාලසටහනක් තුළ ක්‍රෝන් අසමත් වීම මා දුටු බොහෝ විට හේතුවයි. රාත්‍රී 11: 15 ට නියමිත රැකියාවක් 15 23 * * *වෙනුවට * * 11 15 *හෝ වෙනුවට නියම කිරීම ප්‍රායෝගිකයි 11 15 * * *. මධ්‍යම රාත්‍රියෙන් පසු රැකියා සඳහා සතියේ දිනය ද ව්‍යාකූල වේ එම්එෆ් 2-6මධ්‍යම රාත්‍රියෙන් පසුව මිස 1-5. නිශ්චිත දිනයන් සාමාන්‍යයෙන් ගැටළුවක් වන්නේ අප ඒවා කලාතුරකින් භාවිතා කරන * * 3 1 *බැවින් මාර්තු 3 නොවේ. ඔබට විශ්වාස නැතිනම්, https://crontab.guru/ වෙබ් අඩවියෙන් ඔබේ ක්‍රෝන් කාලසටහන් පරීක්ෂා කරන්න .

2/3කාල නියමයන් වැනි සහය නොදක්වන විකල්ප භාවිතා කරමින් විවිධ වේදිකා සමඟ ඔබේ වැඩ කටයුතු අසාර්ථක වීමට හේතු වේ. මෙය ඉතා ප්‍රයෝජනවත් විකල්පයක් වන නමුත් විශ්වීයව ලබාගත නොහැක. 1-5හෝ වැනි ලැයිස්තු සමඟ මම ගැටළු හරහා දුවමි 1,3,5.

නුසුදුසු මාර්ග භාවිතා කිරීම ද ගැටළු ඇති කර තිබේ. පෙරනිමි මාර්ගය සාමාන්‍යයෙන් ක්‍රියාත්මක /bin:/usr/binවන්නේ සම්මත විධානයන් පමණි. මෙම නාමාවලිවල සාමාන්‍යයෙන් අපේක්ෂිත විධානය නොමැත. මෙය සම්මත නොවන විධාන භාවිතා කරන ස්ක්‍රිප්ට් වලටද බලපායි. වෙනත් පරිසර විචල්‍යයන් ද අස්ථානගත විය හැකිය.

දැනට පවතින ක්‍රොන්ටැබ් එක මුළුමනින්ම වසා දැමීම මට ගැටලු ඇති කර තිබේ. මම දැන් ගොනු පිටපතකින් පටවන්නෙමි. මෙය දැනට පවතින ක්‍රොන්ටාබ් crontab -lඑකෙන් ලබා ගත හැක. මම ක්‍රොන්ටාබ් පිටපත ~ / බින් තුළ තබමි. එය පුරාම අදහස් දක්වා ඇති අතර රේඛාවෙන් අවසන් වේ # EOF. මෙය දිනපතා ක්‍රොන්ටාබ් සටහනකින් නැවත පූරණය වේ:

#! / usr / bin / crontab
# මෙම crontab නැවත පූරණය කරන්න
#
54 12 * * * $ OM HOME} / bin / crontab

ඉහත රීලෝඩ් විධානය රඳා පවතින්නේ ක්‍රියාත්මක කළ හැකි ක්‍රොන්ටාබ් මත ය. සමහර පද්ධති සඳහා විධානයෙහි ක්‍රියාත්මක වන crontab අවශ්‍ය වන අතර ගොනුව නියම කළ යුතුය. නාමාවලිය ජාල බෙදාගෙන තිබේ නම්, මම බොහෝ විට crontab.$(hostname)ගොනුවේ නම ලෙස භාවිතා කරමි . මෙය අවසානයේදී වැරදි සේවාදායකයේ වැරදි ක්‍රොන්ටාබ් පටවා ඇති අවස්ථා නිවැරදි කරනු ඇත.

ගොනුව භාවිතා කිරීම මඟින් ක්‍රොන්ටාබ් විය යුතු දේ පිළිබඳ උපස්ථයක් සපයන අතර තාවකාලික සංස්කරණයන් (මා භාවිතා කරන එකම අවස්ථාව crontab -e) ස්වයංක්‍රීයව උපස්ථ කිරීමට ඉඩ දෙයි . උපලේඛනගත කිරීමේ පරාමිතීන් නිවැරදිව ලබා ගැනීමට උපකාරී වන ශීර්ෂයන් ඇත. අද්දැකීම් අඩු පරිශීලකයින් ක්‍රොන්ටැබ් සංස්කරණය කරන විට මම ඒවා එකතු කර ඇත්තෙමි.

කලාතුරකින්, මම පරිශීලක ආදානය අවශ්‍ය විධාන වලට සම්බන්ධ වී සිටිමි. සමහරක් ආදාන යළි හරවා යැවීම සමඟ ක්‍රියා කළත් මේවා ක්‍රොන්ටාබ් යටතේ අසමත් වේ.

ඔබ SSH යතුරු හරහා ගිණුමකට පිවිසෙන්නේ නම් ගිණුමට ප්‍රවේශ විය හැකි නමුත් ගිණුමේ මුරපදය අගුළු දමා ඇති බවක් නොපෙනේ (උදා: කල් ඉකුත්වීම හෝ අවලංගු මුරපද උත්සාහයන් හේතුවෙන්)

පද්ධතිය PAM භාවිතා කරන්නේ නම් සහ ගිණුම අගුළු දමා තිබේ නම්, මෙමඟින් එහි cronjob ක්‍රියාත්මක වීම වළක්වා ගත හැකිය. (මම මෙය සොලාරිස් මත අත්හදා බැලුවෙමි, නමුත් උබුන්ටු මත නොවේ)

ඔබට / var / adm / messages වලින් මෙවැනි පණිවිඩ සොයාගත හැකිය:

ඔක්තෝබර් 24 07:51:00 mybox cron [29024]: [ID 731128 auth.notice] pam_unix_account: දේශීය සත්කාරක සමාගමෙන් අගුළු දැමූ ගිණුම් මයිසර් වලංගු කිරීමට ක්‍රෝන් උත්සාහ කරයි.
ඔක්තෝබර් 24 07:52:00 mybox cron [29063]: [ID 731128 auth.notice] pam_unix_account: දේශීය සත්කාරක සමාගමෙන් අගුළු දැමූ ගිණුම් මයිසර් වලංගු කිරීමට ක්‍රෝන් උත්සාහ කරයි
ඔක්තෝබර් 24 07:53:00 mybox cron [29098]: [ID 731128 auth.notice] pam_unix_account: දේශීය සත්කාරක සමාගමෙන් අගුළු දැමූ ගිණුම් මයිසර් වලංගු කිරීමට ක්‍රෝන් උත්සාහ කරයි
ඔක්.

ඔබ කළ යුත්තේ ධාවනය පමණි:

# passwd -u <USERNAME>

ගිණුම අගුළු ඇරීමට root ලෙස, සහ crontab නැවත ක්‍රියා කළ යුතුය.

=== ඩොකර් අනතුරු ඇඟවීම ===

ඔබ ඩොකර් භාවිතා කරන්නේ නම්,

පසුබිම තුළ ධාවනය කිරීමට මට ක්‍රෝන් සෑදීමට නොහැකි වූ බව එකතු කිරීම සුදුසු යැයි මම සිතමි.

කන්ටේනරය තුළ ක්‍රෝන් ජොබ් එකක් ධාවනය කිරීම සඳහා, මම අධීක්ෂක භාවිතා cron -fකර අනෙක් ක්‍රියාවලිය සමඟ දිව්වෙමි.

සංස්කරණය කරන්න: තවත් ගැටළුවක් - HOST ජාලකරණය සමඟ කන්ටේනරය ධාවනය කිරීමේදී එය ක්‍රියාත්මක කිරීමට මට නොහැකි විය. මෙම ගැටළුව ද මෙහි බලන්න: https://github.com/phusion/baseimage-docker/issues/144

මම ලියන්නේ ස්ථාපන ෂෙල් ස්ක්‍රිප්ටයක් වන අතර එය දත්ත සමුදායකින් පැරණි ගනුදෙනු දත්ත පිරිසිදු කිරීම සඳහා තවත් පිටපතක් නිර්මාණය කරයි. කාර්යයේ කොටසක් ලෙස cron, දත්ත සමුදායේ බර අඩු වූ විට අත්තනෝමතික වේලාවක ධාවනය කිරීම සඳහා දෛනික රැකියාව වින්‍යාස කිරීමට සිදු විය.

මම mycronjobක්‍රෝන් කාලසටහන, පරිශීලක නාමය සහ විධානය සහිත ගොනුවක් සාදා එය /etc/cron.dනාමාවලියට පිටපත් කළෙමි . මගේ ගොචා දෙක:

1. mycronjob ගොනුව ක්‍රියාත්මක කිරීමට root සතු විය යුතුය
2. මට ගොනුවේ අවසරය 644 - 664 ලෙස සැකසීමට සිදු විය.

අවසර ගැටලුවක් /var/log/syslogසමාන දෙයක් ලෙස දිස්වනු ඇත :

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)

පළමු පේළිය /etc/crontabගොනුව සහ පසුව මා යටතේ තැබූ ගොනුවකට යොමු /etc/cront.dවේ.

Crontab තේරුම් නොගන්නා ආකාරයකින් ලියා ඇති රේඛාව. එය නිවැරදිව ලිවිය යුතුය. මෙන්න CrontabHowTo .

ක්‍රෝන් ඩීමන් ධාවනය විය හැකි නමුත් ඇත්ත වශයෙන්ම ක්‍රියා නොකරයි. ක්‍රෝන් නැවත ආරම්භ කිරීමට උත්සාහ කරන්න:

sudo /etc/init.d/cron restart

පේළියක ඇති පරිශීලක නාම තර්කය සමඟ "ක්‍රොන්ටාබ්-ඊ" හරහා ක්‍රොන් වෙත ලිවීම. පරිශීලකයින් (හෝ සයිසැඩ්මින්) ඔවුන්ගේ ෂෙල් ස්ක්‍රිප්ට් ලිවීම සහ ඔවුන් ස්වයංක්‍රීය නොවන්නේ මන්දැයි තේරුම් නොගැනීම පිළිබඳ උදාහරණ මම දැක ඇත්තෙමි. "පරිශීලක" තර්කය පවතින්නේ / etc / crontab තුළ වන නමුත් පරිශීලක අර්ථ දක්වන ලද ගොනු නොවේ. උදාහරණයක් ලෙස, ඔබේ පුද්ගලික ගොනුව මෙවැනි දෙයක් වනු ඇත:

# m h dom mon dow command

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

ෙහෝ / etc / crontab වනුයේ:

# m h dom mon dow user   command

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

ඉතින්, ඔබ දෙවැන්න කරන්නේ ඇයි? හොඳයි, ඔබේ අවසරයන් සකසා ගැනීමට ඔබට අවශ්‍ය ආකාරය මත පදනම්ව, මෙය ඉතා සංවර විය හැකිය. උපක‍්‍රම තේරුම් නොගන්නා, හෝ බේබදුකමට කරදර වීමට අකමැති පරිශීලකයින් සඳහා කාර්යයන් ස්වයංක්‍රීය කිරීම සඳහා මම ස්ක්‍රිප්ට් ලියා ඇත. අවසර ලබා දීමෙන් --x------, ඔවුන්ට එය කියවීමට (සහ සමහර විට අහම්බෙන් වෙනස් වීමට) නොහැකි වන පරිදි ස්ක්‍රිප්ට් ක්‍රියාත්මක කළ හැකිය. කෙසේ වෙතත්, මට මෙම විධානය තවත් ගොනුවකින් තවත් ගොනුවකින් ධාවනය කිරීමට අවශ්‍ය විය හැකිය (එමඟින් නඩත්තු කිරීම පහසු කරයි) නමුත් ගොනු ප්‍රතිදානය නිවැරදි හිමිකරුට පවරා ඇති බවට වග බලා ගන්න. එසේ කිරීමෙන් (අවම වශයෙන් උබුන්ටු 10.10 හි) ගොනුව කියවීමට මෙන්ම ක්‍රියාත්මක කිරීමට ඇති නොහැකියාව මෙන්ම / etc / crontab හි කාල සීමාවන් තැබීමේදී ඉහත සඳහන් කළ ගැටළුව (එය විනෝදජනක ලෙස ප්‍රමාණවත් වන අතර කිසිදු දෝෂයක් ඇති නොකරයි crontab -e) .

නිදසුනක් ලෙස, ෂෙල් ස්ක්‍රිප්ටයට sudo crontab -eඅනුරූපව මූල අවසරයන් සහිත ස්ක්‍රිප්ට් එකක් ධාවනය කිරීමට භාවිතා කළ අවස්ථා මම දැක ඇත්තෙමි chown username file_output. අලස, නමුත් එය ක්රියා කරයි. IMHO, වඩාත් සුන්දර විකල්පය නම් /etc/crontabප්‍රකාශිත පරිශීලක නාමය සහ නිසි අවසරයන් සමඟ එය ඇතුළත් කිරීමයි , එබැවින් file_outputනියම ස්ථානයට සහ හිමිකරු වෙත යන්න.

ආරොන් පර්ට් විසින් වාචික මාදිලිය ගැන සඳහන් කර ඇති දේ ගොඩනඟා ගැනීම, සමහර විට වාචික මාදිලියේ නොමැති ස්ක්‍රිප්ට් ආරම්භ වනු ඇත, නමුත් ඇතුළත් කළ විධානයක පෙරනිමි හැසිරීම නම් ප්‍රොක් එක ආරම්භ වූ වහාම තිරයට රේඛාවක් හෝ ඊට වැඩි ප්‍රමාණයක් ප්‍රතිදානය කිරීමයි. උදාහරණයක් ලෙස, මම අපගේ අන්තර් ජාලය සඳහා උපස්ථ ස්ක්‍රිප්ට් එකක් ලිවූ අතර එය කර්ල් භාවිතා කළ අතර එය දුරස්ථ සේවාදායකයන් වෙත ගොනු බාගත කිරීම හෝ උඩුගත කිරීම සිදුකරන උපයෝගීතාවයක් වන අතර ඔබට HTTP හරහා දුරස්ථ ලිපිගොනු වලට පමණක් ප්‍රවේශ විය හැකි නම් එය ඉතා පහසුය. 'Curl http://something.com/somefile.xls ' භාවිතා කිරීම මා ලියූ පිටපතක් එල්ලීමට හේතු වූ අතර එය කිසි විටෙකත් සම්පුර්ණ නොවූයේ එය නව රේඛාවක් විහිදුවමින් ප්‍රගති රේඛාවක් අනුගමනය කරන බැවිනි. කිසිදු තොරතුරක් ප්‍රතිදානය නොකරන ලෙස පැවසීමට මට නිහ silent ධජය (-s) භාවිතා කිරීමට සිදු වූ අතර ගොනුව බාගත කිරීමට අපොහොසත් වුවහොත් එය හැසිරවීමට මගේම කේතයකින් ලියන්න.

ඔබේ විචල්‍යතාවයේ පරිසර විචල්‍යයන් ඔබට අර්ථ දැක්විය හැකි වුවද, ඔබ ෂෙල් පිටපතක නොමැත. එබැවින් පහත සඳහන් ඉදිකිරීම් ක්‍රියාත්මක නොවනු ඇත:

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}

මෙයට හේතුව විචල්‍යයන් crontable හි අර්ථ නිරූපණය නොකිරීමයි: සියලු අගයන් වචනාර්ථයෙන් ගනු ලැබේ. ඔබ වරහන් අතහැර දැමුවහොත් මෙය සමාන වේ. එබැවින් ඔබගේ විධාන ක්‍රියාත්මක නොවන අතර ඔබේ ලොග් ලිපිගොනු ලියනු නොලැබේ ...

ඒ වෙනුවට ඔබ ඔබේ සියලු පරිසර විචල්‍යයන් කෙලින්ම අර්ථ දැක්විය යුතුය:

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}

කර්තව්‍යයක් ක්‍රෝන් තුළ ක්‍රියාත්මක වන විට, stdin වසා ඇත. ස්ටෙඩින් තිබේද නැද්ද යන්න මත පදනම්ව වෙනස් ලෙස ක්‍රියා කරන වැඩසටහන් ෂෙල් සැසිය සහ ක්‍රෝන් අතර වෙනස් ලෙස හැසිරෙනු ඇත.

goaccessවෙබ් සේවාදායක ලොග් ගොනු විශ්ලේෂණය කිරීමේ වැඩසටහන නිදසුනකි . මෙය ක්‍රෝන් වලින් ක්‍රියා නොකරයි:

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

සහ goaccessවාර්තාව නිර්මාණය කරනවා වෙනුවට උදව් පිටුව පෙන්වයි. කවචයේ දී මෙය ප්‍රතිනිෂ්පාදනය කළ හැකිය

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

සඳහා විසඳුමක් goaccessඑය stdin වෙනුවට ගොනුව කියවීම සිට ලඝු-සටහන කියවා, ඒ නිසා ම විසඳුමක් සඳහා පද්ධතියේ crontab ප්රවේශය වෙනස් කිරීමයි බවට පත් කිරීම

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

ලොග් වීමේ අවසර

ගිණුමෙන් /var/log/ලිවිය නොහැකි නිසා ඉතා සරල ක්‍රොන්ටැබ් එකක් ක්‍රියාත්මක නොවේ luser!

* * * * * /usr/local/bin/teamviewer_check >> /var/log/teamviewer.log 2>&1

විසඳුම: ගොනුව root ලෙස සහ නිර්මාණය chmodකරන්න777

ක්‍රෝන් ලොග් වීම සක්‍රීය කිරීමේ පෙර යෝජනාවට ස්තූතිවන්ත වන අතර /etc/rsyslog.d/50-default.conf, සයිස්ලොග් ප්‍රවේශයට මග පාදයි (No MTA installed, discarding output), පසුව ස්තූතියි “(ක්‍රෝන්) තොරතුරු (එම්ටීඒ ස්ථාපනය කර නැත, ප්‍රතිදානය ඉවතලන්නේ නැත) ,/bin/sh: 1: cannot create /var/log/teamviewer.log: Permission denied

මගේ නඩුවේ ක්‍රොන් සහ ක්‍රොන්ටාබ් වලට විවිධ අයිතිකරුවන් සිටියහ.

වැඩ කරන්නේ නැහැ මට මෙය තිබුණා:

User@Uva ~ $ 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 

මූලික වශයෙන් මට ක්‍රෝන්-වින්‍යාසය ධාවනය කර ප්‍රශ්න වලට නිවැරදිව පිළිතුරු සැපයීමට සිදු විය. මගේ 'පරිශීලක' ගිණුම සඳහා මගේ Win7 පරිශීලක මුරපදය ඇතුළත් කිරීමට අවශ්‍ය වූ ස්ථානයක් තිබේ. මා කියවීමෙන් බැලූ විට, මෙය විභව ආරක්‍ෂිත ගැටළුවක් බව පෙනේ, නමුත් තනි නිවාස ජාලයක එකම පරිපාලකයා මම බැවින් මම එය හරි යැයි තීරණය කළෙමි.

මෙන්න මට යන්නට ලැබුණු විධාන අනුක්‍රමය:

User@Uva ~ $ 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 cygwin@cygwin.com.
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.


User@Uva ~ $ 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

User@Uva ~ $

ඔබගේ පරිශීලකයාගේ මුරපදය කල් ඉකුත්වී ඇත්නම් ක්‍රෝන් රැකියා ක්‍රියාත්මක නොවේ.

මෙහි එක් ඇඟවුමක් නම්, ඔබේ ක්‍රෝන් ලොගයේ (සාමාන්‍යයෙන් /var/log/syslogඋබුන්ටු වල, මම විශ්වාස කරමි) "සත්‍යාපන ටෝකනය තවදුරටත් වලංගු නොවේ; නව එකක් අවශ්‍ය වේ" වැනි පණිවිඩ තිබේ නම්.

ධාවනය කිරීමෙන් ඔබට මෙම ගැටළුව පරීක්ෂා කළ හැකිය sudo chage -l the_username.

කල් ඉකුත් වූ මුරපදයක උදාහරණයක් මෙන්න:

$ sudo chage -l root
Last password change                    : password must be changed
Password expires                    : password must be changed
Password inactive                   : password must be changed
Account expires                     : never
Minimum number of days between password change      : 0
Maximum number of days between password change      : 14600
Number of days of warning before password expires   : 14

නිවැරදි කිරීම මුරපදය වෙනස් කිරීමයි. උදාහරණයක් වශයෙන්:

sudo -u root passwd

ඉන්පසු උපදෙස් අනුගමනය කරන්න, නව මුරපදයක් නියම කර ඇති පරිදි සඳහන් කරන්න.

මාව නිවැරදි දිශාවට යොමු කිරීම සඳහා /server/449651/why-is-my-crontab-not-working-and-how-can-i-troubleshoot-it#comment966708_544905 ට ස්තූතියි . මගේ කාරණයේදී, එම විවරණකරු මෙන්ම, එය ඩිජිටල් ඕෂන් පෙට්ටියක මූල පරිශීලකයා විය.