Cron Nie Działa - Co Jest źle Ustawione?

[goodi]

Witam wszystkich

 

Przejrzałem wyszukane na tym forum i nie tylko wątki związane z kłopotami z uruchamianiem przez crona skryptów, ale nie udało mi się rozwiązać problemu. A mam taki problem: napisałem skrypt, który raz na dobę powinien mi zrobić archiwum bazy danych. Skrypt uruchamiany ręcznie poleceniem

 

/bin/bash /etc/cron.daily/rman_backup.sh

 

działa bez problemu. Natomiast wstawiony w plik /etc/crontab nie działa. Wpis w crontab wygląda następująco:

 

SHELL=/bin/bash

PATH=/sbin:/bin:/usr/sbin:/usr/bin

MAILTO=root

HOME=/

# run-parts

1 * * * * root run-parts /etc/cron.hourly

#

0 5 * * * root run-parts /etc/cron.daily

#

0 4 * * 7 root run-parts /etc/cron.weekly

#

42 4 1 * * root run-parts /etc/cron.monthly

#

00 23 * * * root /etc/cron.daily/rman_backup.sh

 

Skrypt siedzi w folderze cron.daily, bo miałem nadzieję, że jak go tam wrzucę, to zostanie wykonany razem w innymi zadaniami, ale gdzie tam. Akurat to jest pomijane.

 

Powyższy skrypt powinien zostać odpalony codziennie o 23:00. Zamiast tego w dzienniku systemowym o wyznaczonej godzinie pojawia mi się w sekcji cron następujący wpis:

 

Apr 1 23:00:01 Server CROND[22809]: (root) CMD (/etc/cron.daily/rman_backup.sh)

 

I tyle. Kopia nie jest wykonywana. Czy ktoś z Was jest w stanie podpowiedzieć mi, o co tu biega?

 

Pozdrawiam

[jjj]

Nie. To, co stworzyłeś, nie jest skryptem systemowym, który miałby być wywołany przez crona, ale tabelą działań crona. Takie coś instaluje się dla użytkownika poleceniem crontab <plik>.

Skrypty (dla basha, nie dla crona) wstawione do /etc/cron.daily będą wywoływane przez crond codziennie bez konieczności tworzenia osobnych tabel. Podobnie inne kartoteki cron.*.

[morsik]

Dla pewności spytam, ustawiłeś +x dla tego skryptu?

[goodi]

jjj, wiem że to, co pokazałem, jest tabelą dla crona. Skrypt o nazwie rman_backup.sh początkowo wcale w niej nie był zamieszczony, ponieważ wrzuciłem go do folderu /etc/cron.daily. Problem jednak jest taki, że on nie jest przez crona uruchamiany. Dlatego dla pewności stworzyłem powyższy wpis w tabeli. Myślałem, że to pomoże, ale niestety nic z tego. Skrypt archiwizujący nadal nie jest przez crona uruchamiany. A w zasadzie chyba jest, skoro pojawia się wpis

 

Apr 1 23:00:01 Server CROND[22809]: (root) CMD (/etc/cron.daily/rman_backup.sh)

 

tylko pliki kopii nie są tworzone.

Z tego powodu już zgłupiałem. Skoro wpis o uruchomieniu skryptu pojawia się w dzienniku, to dlaczego nie widać efektu, podczas gdy przy ręcznym uruchomieniu tego samego skryptu kopia jest tworzona prawidłowo.

 

morsik - nie ustawiałem nic takiego. Ustawiłem za to we właściwościach pliku rman_backup.sh, żeby był uruchamiany jako program.

[borzole]

Miałem kiedyś podobny problem, bo próbowałem robić zadania dostępne tylko dla root, a wpis był w cron usera.

To jest wpis dla cron usera, czy root (pytam, bo nie rozumiem tego 'root run-parts')?

 

*widzę, że używasz X'ow (wnioskuje po tym komentarzu do +x ), to masz nakładkę na crona gnome-schedule, tylko pamiętaj żeby z poziomu root uruchomić

 

[goodi]

Używam X-ów, bo "zawziętym" użytkownikiem Linuksa jestem z konieczności. Cały software, na jakim pracuję, jest wyłącznie pod Windows (i żadne emulatory Windows na Linuksie tu nie pomogą, bo już tak kombinowałem) , a serwer w sieci musiałem bezwzględnie postawić na Linuksie. Nie powiem, żebym narzekał, bo system mi się podoba, ale dopiero zaczynam się go intensywnie uczyć, więc trochę czasu zejdzie, zanim będę mógł powiedzieć, że umiem go bezbłędnie obsługiwać (o administracji na razie nie wspomnę ).

 

Nie zakładałem tabel crona dla żadnego konta, jedynie odpaliłem /etc/crontab i edytowałem zawartość. Może to jest przyczyną problemów...

[borzole]

Nie zakładałem tabel crona dla żadnego konta, jedynie odpaliłem /etc/crontab i edytowałem zawartość.

na pewno odpaliłeś tak # /etc/crontab a nie tak $ /etc/crontab ?

 

[goodi]

na pewno odpaliłeś tak # /etc/crontab a nie tak $ /etc/crontab ?

 

Po kilku kombinacjach mogę tylko powiedzieć, że odpalałem polecenie /etc/crontab zarówno na koncie roota, jak i użytkownika. To, co zamieściłem na początku, jest skopiowane z wyniku uruchomienia pliku /etc/crontab w formie graficznej, "najordynarniejszym dwuklikiem" z konta usera.

W sumie nie ma problemu, na jakim koncie to odpalę, bo mogę ustawić prawo własności na dowolne konto, byle to tylko zadziałało. Jak na razie baza Oracle śmiga mi bez regularnych kopii i zastanawiam się tylko, kiedy ... Nie dokończę, żeby nie zapeszyć.

[Adi1981]

Lepiej pokaż co masz mniej więcej w skrypcie

[goodi]

Lepiej pokaż co masz mniej więcej w skrypcie

 

A prosszz...

 

/bin/bash

 

# Declare your environment variables

export ORACLE_SID=XE

export ORACLE_BASE=/usr/lib/oracle/xe/oradata/ss

export ORACLE_HOME=/usr/lib/oracle/xe/app/oracle/product/10.2.0/server

export PATH=$PATH:${ORACLE_HOME}/bin

 

# Start the rman commands

rman target=/ << EOF

OPEN DATABASE;

CONFIGURE CONTROLFILE AUTOBACKUP ON;

CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/home/oracle/autobackup_control_file%F';

CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 14 DAYS;

run {

CROSSCHECK BACKUP;

sql 'ALTER SYSTEM SWITCH LOGFILE';

sql 'ALTER SYSTEM CHECKPOINT';

BACKUP AS COMPRESSED BACKUPSET DATABASE FORMAT '/home/oracle/databasefiles_%d_%u_%s_%T';

sql 'ALTER SYSTEM ARCHIVE LOG CURRENT';

BACKUP AS COMPRESSED BACKUPSET ARCHIVELOG ALL FORMAT '/home/oracle/archivelogs_%d_%u_%s_%T' DELETE INPUT;

BACKUP AS COMPRESSED BACKUPSET CURRENT CONTROLFILE FORMAT '/home/oracle/controlfile_%d_%u_%s_%T';

CROSSCHECK BACKUP;

DELETE NOPROMPT OBSOLETE;

DELETE NOPROMPT EXPIRED BACKUP;

}

EXIT;

EOF

#

[Adi1981]

pierwsza linia jest

/bin/bash

czy

#!/bin/bash

?

Jeśli to pioerwsze, to zmień na #!, natomiast jesli masz z #!, to jedyne co mi przychodzi do głowy to po prostu ścieżki do komend. Co prawda exportujesz $PATH, ale nie deklarujesz jej wcześniej bezpośrednio w skrypcie, a z bashem i cronem są czasem różne jaja. Co prawda #! powinno to załatwić ale... Spróbuj z pełną ścieżką do rman, albo daj wcześniej PATH=/usr/bin (czy gdzie jest usadowiony rman)

[goodi]

To jest dokładna zawartość skryptu. Zaczyna się od

 

/bin/bash

 

RMan siedzi w /usr/lib/oracle/xe/app/oracle/product/10.2.0/server/bin, czyli ścieżka do niego jest zadeklarowana w PATH jako ${ORACLE_HOME}/bin.

 

Ścieżek do poszczególnych komend nie da się pozmieniać, bo są to wszystko komendy odpalane pod RManem, a ten jest uruchamiany na początku skryptu. Ale spróbuję jeszcze faktycznie uruchomić RMana z pełnej ścieżki. No i zmienię początek skryptu na #!. Może zadziała... Dzięki.

[goodi]

Ponieważ, tak jak napisałem wyżej, użytkownikiem jestem na razie z przymusu, mam jeszcze jedno pytanie, bo nie chciałbym zaczynać działania, jeżeli miałoby być z góry skazane na niepowodzenie.

Mam ograniczony dostęp do serwera, więc wygodniej byłoby mi odtworzyć warunki do testowania na własnym sprzęcie. Niestety, serwer stoi na F8, a na moim sprzęcie (laptop) Fedora nie daje się zainstalować za nic w świecie. Dlatego testy i ew. zmiany ustawień crona wprowadzane byłyby na Debianie 4.0, który na tym laptopie działa bez problemu.

Pytanie brzmi: czy różnica w dystrybucjach ma jakieś znaczenie? Czy jeżeli dogram temat na Debianie, to może mieć jakiś wpływ na ew. "nie zadziałanie" wszystkiego później na Fedorze?

[Adi1981]

Co do działania samego skryptu i crona myślę że nie powinno mieć to specjalnego znaczenia na jakim systemie odpalasz. Natomiast dodaj #! przed /bin/bash, prawidłowa deklaracja języka tórego używasz w skrypcie zawsze musi się zaczynać od #!, czyli

#!/bin/bash

W zasadzie to chyba jedno o co się można było doczepić tutaj...

 

Możesz w sumie jeszcze w cronie spróbować

su -
crontab -e
00 23 * * * sh /etc/cron.daily/rman_backup.sh

Co prawda +x na skrypcie powinien być ok,ale spróbować z wywołaniem shella bezpośrednio w cronie nie zaszkodzi spróbować.