Miért nem működnek a crontab szkriptek?

456

Gyakran acrontab szkriptek nem futnak ütemterv szerint vagy várt módon. Ennek számos oka van:

  1. rossz crontab jelölés
  2. engedélyezési probléma
  3. környezeti változók

Ez a közösség wiki célja acrontab szkriptek legfontosabb okainak összevonása, amelyek nem a várakozásoknak megfelelően fejeződnek be. Írjon minden okot külön válaszként.

Kérjük, adjon meg egy okot válaszonként - részleteket arról, hogy miért nincs végrehajtva - és javítsa meg ezt az okot.

Kérjük, csak cron-specifikus kérdéseket írjon fel, pl. parancsok, amelyek a várakozásoknak megfelelően végrehajtódnak a héjból, de a cron hibásan végrehajtják.

    
készlet Adam Matan 08.05.2017 20:15
forrás

46 válasz

432

Különböző környezet

A Cron minimális környezeti változókat ad a munkáinak. Ha látni szeretné a különbséget, adjon hozzá ehhez hasonló próbabábut:

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

Várja meg a/tmp/env.output létrehozását, majd távolítsa el újra a feladatot. Most hasonlítsa össze a/tmp/env.output tartalmát aenv kimenetével a rendszeres terminálon.

A közös "gotcha" itt aPATH környezeti változó különbözik. Lehet, hogy a cron szkript asomecommand -ot/opt/someApp/bin -ban találta meg, amelyet hozzáadott a (z)PATH -ban a (z)/etc/environment -ban? A cron figyelmen kívül hagyja aPATH -ot az adott fájlból, ezért a parancsfájlból származó runnningsomecommand sikertelen lesz a cron futtatásakor, de a terminálon futtatva működik. Érdemes megjegyezni, hogy a (z)/etc/environment változók átkerülnek a cron feladatokra, nem csak a változók cron kifejezetten beállítja magát, mint aPATH.

Ahhoz, hogy megkerülhesse, csak állítsa be sajátPATH változóját a szkript tetején. Például.

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

# rest of script follows

Néhányan inkább csak abszolút elérési utakat használnak az összes parancsra. Ez ellen szólok. Fontolja meg, hogy mi történik, ha a szkriptet más rendszeren szeretné futtatni, és ezen a rendszeren a parancs/opt/someAppv2.2/bin helyett. A teljes scriptet a/opt/someApp/bin helyett a/opt/someAppv2.2/bin -al kell átírnod, ahelyett, hogy csak egy kis szerkesztést hajthatsz végre a szkript első sorában.

Beállíthatja a PATH változót a crontab fájlban is, amely minden cron feladatra vonatkozik. Például.

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

15 1 * * * backupscript --incremental /home /root
    
válasz adott geirha 27.02.2018 19:47
forrás
292

Az én top gotcha: Ha elfelejtetted új sort adni acrontab fájl végén. Más szavakkal, a crontab fájlnak üres sorral kell végződnie.

Az alábbiakban az erre a témára vonatkozó man oldalak vonatkozó része (man crontab, majd ugrás a végére):

   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)
    
válasz adott user4124 02.02.2011 21:32
forrás
125

A Cron démon nem fut. Nagyon elrontottam ezt néhány hónappal ezelőtt.

Típus:

pgrep cron 

Ha nem látsz számot, akkor a cron nem fut. sudo /etc/init.d/cron start használható a cron indításához.

SZERKESZT: Ahelyett, hogy az inet parancsfájlokat az /etc/init.d címen keresztül meghívná, használja a szolgáltatást segédprogram, például

sudo service cron start
    
válasz adott 4 revs, 4 users 38%user6019 26.01.2012 11:57
forrás
83

A (z)cron.d/,cron.daily/,cron.hourly/ stb. szkriptfájlnevek nem tartalmazhatnak pontot (.), különben a futó részek kihagyják őket.

Lásd a futó részeket (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_-]+$).

Szóval, ha van egy cron scriptbackup.sh,analyze-logs.pl incron.daily/ könyvtárat, akkor a legjobb a kiterjesztés nevek eltávolítása.

    
válasz adott Xiè Jìléi 10.01.2017 16:20
forrás
56

Sok környezetben a cron végrehajtja a parancsokat ash használatával, míg sokan azt feltételezik, hogy abash -t használja.

Javaslatok ennek a hibás parancsnak a tesztelésére vagy javítására:

  • Próbálja meg futtatni a parancsot a (z)sh -ban, hogy megnézze, működik-e
  • Vezesse be a parancsot egy bash subshell-ben, és győződjön meg arról, hogy fut-e a bash-ben:
    bash -c "mybashcommand"
  • Mondja el, hogy a cron a parancs összes parancsát a crontab tetején állítja be:
    SHELL=/bin/bash
  • Ha a parancs parancsfájl, győződjön meg róla, hogy a szkript egy shebang-ot tartalmaz:
    #!/bin/bash
válasz adott Ian Mackinnon 25.06.2011 21:30
forrás
34

Néhány kérdésem volt az időzónákkal kapcsolatban. A Cron futott a friss telepítési időzónával. A megoldás a cron újraindítása volt:

sudo service cron restart
    
válasz adott luissquall 07.02.2012 15:49
forrás
29

Ha a crontab parancsnak benne van% szimbóluma, akkor a cron megpróbálja értelmezni. Tehát, ha olyan parancsot használsz, amelyben benne van% (például a dátum parancsnak megfelelő formátum specifikáció), akkor el kell menekülnöd.

Ez és más jó ittok: link

    
válasz adott JMS 26.08.2012 08:59
forrás
28

Abszolút útvonalat kell használni a szkriptekhez:

Például/bin/grep agrep helyett:

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

Ahelyett, hogy:

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

Ez különösen bonyolult, mert ugyanaz a parancs fog működni, ha a shell-ből hajt végre. Ennek oka, hogy acron nem ugyanaz aPATH környezeti változó, mint a felhasználó.

    
válasz adott Adam Matan 24.01.2011 11:02
forrás
23

Lehetséges, hogy a felhasználó jelszava lejárt. A root jelszava is lejár. tail -f /var/log/cron.log, és a cron sikertelen lesz a jelszó lejárta után. Beállíthatja a jelszót, hogy soha ne járjon le:passwd -x -1 <username>

Egyes rendszereknél (Debian, Ubuntu) a cron naplózása alapértelmezés szerint nincs engedélyezve. Az /etc/rsyslog.conf vagy /etc/rsyslog.d/50-default.conf sorban:

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

módosítani kell (sudo nano /etc/rsyslog.conf) a következőket:

cron.*                          /var/log/cron.log

Ezt követően újra kell indítanod az rsyslogot

/etc/init.d/rsyslog restart

vagy

service rsyslog restart 

Forrás: A crontab naplózásának engedélyezése a Debian Linux-ban

Egyes rendszereknél (Ubuntu) a különálló naplófájl a cron számára alapértelmezés szerint nincs engedélyezve, de a cronhoz kapcsolódó naplók megjelenhetnek a syslog fájlban. Használhatja

cat /var/log/syslog | grep cron

a cronhoz kapcsolódó üzenetek megtekintéséhez.

    
válasz adott 6 revs, 5 users 34%unknown 11.05.2016 12:48
forrás
21

A Cron parancsfájlt hív, amely nem végrehajtható.

Achmod +x /path/to/scrip parancs futtatásával a szkript végrehajthatóvá válik, és megoldja ezt a problémát.

    
válasz adott jet 26.01.2011 19:24
forrás
16

Ha a cronjob meghívja a GUI-alkalmazásokat, meg kell mondania nekik, hogy milyen DISPLAY-t kell használniuk.

Példa: Firefox elindítása a cron segítségével.

A szkriptnek tartalmaznia kell aexport DISPLAY=:0 valahol.

    
válasz adott andrew 26.07.2012 17:46
forrás
14

Engedélyezési problémák meglehetősen gyakoriak, attól tartok.

Ne feledje, hogy egy közös megoldás, ha mindent végrehajtunk a root crontab használatával, ami néha egy valóban rossz ötlet. A megfelelő engedélyek beállítása határozottan nagyrészt figyelmen kívül hagyott kérdés.

    
válasz adott user9521 26.01.2011 16:53
forrás
13

Bizonytalan cron tabulátus

A cron táblázat elutasítva a> ha engedélye nem biztonságos

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)

A probléma megoldódott

# correct permission
sudo chmod 600 /var/spool/cron/crontabs/user
# signal crond to reload the file
sudo touch /var/spool/cron/crontabs
    
válasz adott John Peterson 15.06.2013 05:12
forrás
11

A parancsfájl helyérzékeny. Ez azzal függ össze, hogy mindig abszolút útvonalakat használnak egy szkriptben, de nem teljesen ugyanaz. A cron-munkának szüksége lehetcd -ra egy adott könyvtárra a futtatás előtt, pl. egy rake-feladat egy Rails alkalmazásban lehet, hogy a Rake alkalmazásban legyen a megfelelő feladat megtalálása, nem beszélve a megfelelő adatbázis-konfigurációról stb.

Tehát egy

crontab bejegyzést

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

jobb lenne, mint

23 3 * * * cd /var/www/production/current && /usr/bin/rake db:session_purge RAILS_ENV=production

Vagy, hogy a crontab bejegyzés egyszerűbb és kevésbé törékeny legyen:

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

a következő kóddal:/home/<user>/scripts/session-purge.sh:

cd /var/www/production/current
/usr/bin/rake db:session_purge RAILS_ENV=production
    
válasz adott pjmorse 29.11.2011 16:20
forrás
10

A Crontab specifikáció amely múltban dolgozott megszakadhat, ha egy crontab fájlból átmásolódik. Néha az az oka, hogy a specifikációt a rendszer crontab fájljából egy felhasználói crontab fájlba helyeztük át, vagy fordítva.

A cron job specifikáció formátuma különbözik a felhasználói crontab fájlok (/ var / spool / cron / username vagy / var / spool / cron / crontabs / felhasználónév) és a rendszer crontabs (/etc/crontab és a% co_kde %).

A rendszer crontabs-nak van egy extra "felhasználói" mezője a parancsfuttatás előtt.

Ez olyan hibákat okozhat, mint a /etc/cron.d , amikor egy parancsot ageorge; command not found -ból vagy a/etc/crontab fájlból a felhasználó crontab fájljába helyez.

Ezzel szemben a cron a /etc/cron.d vagy a hasonló hibák esetén fordul elő, ha fordítva történik.

    
válasz adott pbr 25.10.2013 17:04
forrás
9

A cron parancsfájl a --verbose opcióval

parancsra hivatkozik

A cron parancsfájl sikertelen volt, mert autopilotban voltam a parancsfájl beírása közben, és a --verbose opciót is beleértve:

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

A parancsfájl jól futott a shell-ból, de sikertelen volt, amikor a crontab-ból fut, mert a verbose kimenet a shell-ből futtatva stdout-ra változik, de senki sem fut, amikor fut a crontab-ból. Egyszerű megoldás a 'v' eltávolításához:

#!/bin/bash
some commands
tar cfz /my/archive/file.tar.gz /my/shared/directory
some more commands
    
válasz adott Aaron Peart 03.06.2012 08:59
forrás
7

A leggyakoribb ok, amiért a cron sikertelenül bejelölte a rosszul meghatározott menetrendet. Elvégzi a munkát, amelyet a30 23 * * * helyett* * 11 15 * vagy11 15 * * * helyett 11:15 óráig terveznek. A hét napja a munkahelyek után éjfél után is zavaros lesz M-F2-6 éjfél után nem1-5. A konkrét dátumok rendszerint probléma, mivel ritkán használjuk őket* * 3 1 * nem március 3.

Ha a nem támogatott opciók, például a2/3 időbeli specifikációkat használó különböző platformokkal végzett munkája is hibákat okozhat. Ez egy nagyon hasznos lehetőség, de nem általánosan elérhető. Futtattam az olyan problémák listáit is, mint a1-5 vagy1,3,5.

A nem minősített útvonalak használata szintén problémákat okozott. Az alapértelmezett elérési út általában/bin:/usr/bin, így csak a standard parancsok futnak. Ezek a könyvtárak általában nem rendelkeznek a kívánt paranccsal. Ez a nem szabványos parancsokat használó szkriptekre is hatással van. Más környezeti változók is hiányozhatnak.

A meglévő crontab teljesítése teljesen problémákat okozott nekem. Most betöltöttem egy fájlt. Ezt a meglévő crontab-ból visszaállíthatjuk acrontab -l -ot használva, ha ez meggörbül. A crontab példányát a ~ / bin-ben tartom. Ezt a# EOF vonal egészével és végével fejezi be. Ez naponta töltődik be egy crontab bejegyzésből, mint például:

#!/usr/bin/crontab
# Reload this crontab
#
54 12    *   *   *   ${HOME}/bin/crontab

A fenti újratöltési parancs egy futtatható crontab-ra támaszkodik egy crontab futtatásával. Egyes rendszereknél a futó crontab parancsot kell megadni, és meg kell adni a fájlt. Ha a könyvtár megosztja a hálózatot, gyakran acrontab.$(hostname) -ot használom a fájl neveként. Ez végül kijavítja azokat az eseteket, amikor a rossz címtartományt a rossz kiszolgálóra töltötte.

A fájl használata biztosít egy biztonsági másolatot arról, hogy mi legyen a crontab, és lehetővé teszi az ideiglenes szerkesztéseket (az egyetlen alkalom, amikor acrontab -e -ot használom). Vannak olyan fejlécek is, amelyek segítenek az ütemezési paraméterek jobb elérésében. Hozzáadtam azokat, amikor a tapasztalatlanság felhasználóinak szerkeszteni fogják a crontabot.

Ritkán olyan felhasználói parancsokat igénylő parancsokat futtattam be. Ezek a crontab alatt sikertelenek, bár egyesek a bemeneti átirányítással dolgoznak.

    
válasz adott BillThor 01.02.2011 19:37
forrás
6

Ha SSH kulcsok segítségével fiókot használ, lehetséges a fiókba való bejelentkezés, de nem veszi észre, hogy a fiók jelszava le van zárva (például lejárt vagy érvénytelen jelszó kísérletek miatt)

Ha a rendszer PAM-ot használ, és a fiók zárolva van, akkor ez megakadályozhatja a cronjob futását. (Ezt a Solaris-ban teszteltem, de nem az Ubuntuban)

Ilyen üzenetek találhatók a / var / adm / messages:

mappában
Oct 24 07:51:00 mybox cron[29024]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host
Oct 24 07:52:00 mybox cron[29063]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host
Oct 24 07:53:00 mybox cron[29098]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host
Oct 24 07:54:00 mybox cron[29527]: [ID 731128 auth.notice] pam_unix_account: cron attempting to validate locked account myuser from local host

Mindössze annyit kell tennie, hogy futtatható:

# passwd -u <USERNAME>

rootként a fiók feloldásához, és a crontab újra kell működnie.

    
válasz adott JohnGH 24.10.2012 09:22
forrás
4

Ha van ilyen parancsod:

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

és nem működik, és nem látsz semmilyen kimenetet, akkor ez nem feltétlenül jelenti azt, hogy a cron nem működik. A parancsfájl megszakadhat, és a kimenet az stderr kimenetre kerül, amely nem jut át ​​a / tmp / kimenetre. Ellenőrizze, hogy ez nem így van, ezt a kimenetet is rögzíti:

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

, hogy lássuk, segít-e ez a probléma.

    
válasz adott Philluminati 18.04.2018 20:26
forrás
3

=== Docker riasztás ===

Ha dokkolóval dolgozik,

Úgy gondolom, helyes hozzáfűzni, hogy nem sikerült a cron futni a háttérben.

A konténeren belüli cron-munka futtatásához felügyelőt használtam, és acron -f -ot a másik folyamattal együtt futtattuk.

Szerkesztés: Egy másik kérdés - Nem sikerült a munkát a konténer HOST-hálózatba való futtatásakor elvégezni. Ez a probléma itt is olvasható: link

    
válasz adott AlonL 20.05.2015 17:48
forrás
3

Az én esetemben a cron és a crontab különböző tulajdonosokkal rendelkezett.

NEM működött Ez volt:

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 

Alapvetően a cron-config-ot kellett futtatnom és helyesen válaszoltam a kérdésekre. Van egy olyan pont, ahol be kellett írnom a Win7 felhasználói jelszavamat a "Felhasználó" fiókomhoz. Az olvasástól megtettem, úgy tűnik, ez egy lehetséges biztonsági probléma, de én vagyok az egyetlen rendszergazda egyetlen otthoni hálózaton, ezért úgy döntöttem, hogy rendben van.

Itt van a parancssorozat, amely meghozta:

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 ~ $
    
válasz adott KiloOne 10.12.2015 10:20
forrás
3

Telepített parancsfájlt írtam, amely egy másik szkriptet hoz létre a régi tranzakciós adatok törléséhez egy adatbázisból. A feladat részeként napi cron munkát kellett beállítania tetszőleges idő alatt, amikor az adatbázis terhelése alacsony volt.

létrehoztam egymycronjob fájlt a cron ütemtervvel, felhasználónévvel & a parancsot, és átmásolta a/etc/cron.d könyvtárba. A két hülyeim:

  1. Amycronjob fájlnak a gyökér tulajdonát kell futtatni
  2. A fájl engedélyezését 644 - 664-re kellett állítanom.

Az engedélyezési probléma a (z)/var/log/syslog -ban hasonló:

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)

Az első sor a/etc/crontab fájlra és a későbbiekben a/etc/cront.d alatt található fájlra vonatkozik.

    
válasz adott Izik Golan 24.04.2017 21:53
forrás
2

A crontab által oly módon írt sor, amelyet nem értenek. Helyesen kell megírni. Itt CrontabHowTo .

    
válasz adott Kangarooo 02.02.2011 20:52
forrás
2

A Cron démon futhat, de nem működik. Próbálja meg újraindítani a cron:

sudo /etc/init.d/cron restart
    
válasz adott Phil Dodd 25.11.2011 00:20
forrás
2

Cronba írva a "crontab -e" -ot a sor felhasználónév argumentumával. Láttam példákat a felhasználók (vagy a rendszergazdák), hogy írják be a parancsfájlokat, és nem értik meg, hogy miért nem automatizálják őket. A "user" argumentum létezik az / etc / crontab fájlban, de nem a felhasználó által definiált fájlok. így például a személyes fájlod valami hasonló lenne:

# m h dom mon dow command

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

mivel a / etc / crontab lenne:

# m h dom mon dow user   command

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

Szóval miért tenné ezt az utat? Nos, attól függően, hogy hogyan szeretné beállítani a jogosultságait, ez nagyon összetört lehet. Szkripteket írtam, hogy automatizálhassam azokat a feladatokat, akik nem értik a bonyolultságokat, vagy nem akarnak zavarni a dolgokat. Ha engedélyeket állít be--x------ -ra, akkor végrehajthatóvá teheti a szkriptet anélkül, hogy képes lenne olvasni (és esetleg véletlenül megváltoztatni). Azonban szeretnék futtatni ezt a parancsot egy másik fájlból (így könnyebb fenntartani), de győződjön meg róla, hogy a fájl kimenet a megfelelő tulajdonoshoz van rendelve. Ennek során (legalábbis az Ubuntu 10.10-ben) megtörténik mind a fájlok olvasásának képtelensége, mind a végrehajtás, valamint a fent említett probléma, amikor az / etc / crontab fájlba helyezzük a periódusokat (ami eléggé eléggé hibát okoz acrontab -e).

Példaként asudo crontab -e példányokat futtatni root jogosultsággal rendelkező parancsfájl futtatásához, a megfelelőchown username file_output -ban a shell parancsfájlban. Sloppy, de működik. IMHO, A kecsesebb lehetőség az, hogy a/etc/crontab -ot a megadott felhasználónévvel és a megfelelő jogosultságokkal adjuk meg, így afile_output a megfelelő helyre és tulajdonosra lép.

    
válasz adott Mange 12.06.2012 19:42
forrás
2

Azzal, hogy az Aaron Peart elmondta, milyen szórakoztató módról van szó, néha a szkriptek nem szőkös módban inicializálják, de nem fejeződnek be, ha egy beillesztett parancs alapértelmezett viselkedése egy sor vagy több egy vagy több képernyő kimenetét adja ki a képernyőn a proc indításakor. Például írtam egy biztonsági parancsfájlt az intranetünknek, amely a curl-et használta, amely fájlokat tölt le vagy tölt fel a távoli szerverekre, és nagyon hasznos, ha csak a távoli fájlokat HTTP-n keresztül érheti el. A "curl link használatával egy olyan szkriptet okozott, amelyet azért írtam, hogy lógjon és soha ne töltsön be, mert egy új sort követ, amelyet egy progresszív sor követ. A csendes zászlót (-s) kellett használnod ahhoz, hogy ne adjon ki semmilyen információt, és írjon a saját kódomba, hogy kezelje, ha a fájl nem sikerült letölteni.

    
válasz adott Mange 12.06.2012 22:06
forrás
2

Habár környezeti változókat is definiálhat a címezhető formában, nem vagy shell parancsfájlban. Tehát a következőképpen nem működik:

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}

Ez azért van, mert a változók nem értelmezhetők a crontable-ben: minden értéket litterálisan veszünk. És ez ugyanaz, ha kihagyja a zárójeleket. Így a parancsok nem futnak, és a naplófájljaid nem fognak írni ...

Ehelyett meg kell határoznia az összes környezeti változót:

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}
    
válasz adott Alexandre 07.06.2013 11:13
forrás
2

Ha egy feladat fut a cron alatt, a stdin zárva van. Azok a programok, amelyek másként működnek attól függően, hogy a stdin rendelkezésre áll-e vagy sem, eltérő módon fog viselkedni a shell munkamenet és a cron között.

Példa agoaccess programra a webszerver naplófájljainak elemzéséhez. Ez nem működik a cron-ban:

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

és agoaccess a jelentés létrehozása helyett a súgó oldalt jeleníti meg. A héjban ez

-nel reprodukálható
goaccess -a -f /var/log/nginx/access.log > output.html < /dev/null

A (z)goaccess javításhoz olvassa el a naplófájlt a stdin-ból a fájl olvasása helyett, így a megoldás a crontab bejegyzés módosítása

cat /var/log/nginx/access.log | goaccess -a > output.html
    
válasz adott Martijn de Milliano 09.08.2013 22:27
forrás
2

Az RHEL7 kiszolgálón root cron feladatok futnak, de a felhasználói munkák nem. Megállapítottam, hogy otthoni címtár nélkül a feladatok nem futnak (de a / var / log / cronban jó hibákat találsz). A saját könyvtár létrehozásakor a probléma megoldódott.

    
válasz adott Dennis Parslow 02.02.2017 22:29
forrás
2

Ha szerkesztette a crontab fájlt egy windows szerkesztővel (samba vagy valami), és az új sorokat a \ n \ r vagy csak \ r \ n helyettesítette, a cron nem fog futni.

Továbbá, ha a /etc/cron.d/* címet használja, és az egyik ilyen fájlban van, akkor a cron átmegy a fájlokon, és megáll, ha rossz fájlt talál. Nem biztos benne, hogy ez a probléma?

A

od -c /etc/cron.d/* | grep \r
    
válasz adott Doug 20.04.2017 03:38
forrás