Forum Debian Users Gang

Na początek lekkie sprostowanie - chodzi o SUSE nie o Deb'a, ale zasada jest w sumie ta sama....

Od kilku dni zastanawiam się co się mogło 'sypnąć'...

Projekt polega na uruchomieniu cyklicznego wykonywania kopii zapasowej codziennie o określonej godzinie.
Aby sprawdzić funkcjonowanie crona w tabeli crontaba (etc/crontab) dodałem odpowiedni wpis testowy czyli np.:

*/1 * * * * root echo "test_$(date +%Y%m%d_[%H:%M:%S]) " >> /home/test.txt

Wszystko ładnie pięknie... Zamieniłem zatem w/w wpis na wywołanie skryptu wykonującego kopie zapasowe kopii PostgreSQL. Jest to gotowiec, który już był w systemie - nie znam szczegółów - ktoś inny instalował SLES'a i bazę danych.
W każdym razie wykonując 'z palca'

# /srv/jboss_std/AdmNarz/./backup_create.sh

tworzy się kopia na 'żywej' bazie tj. w trakcie pracy i w efekcie zapisuje plik *.dump tworząc przedtem folder z bieżącą datą w odpowiednim katalogu.

Po modyfikacjach crona:

*/10 * * * * root /srv/jboss_std/AdmNarz/./backup_create.sh

(co 10min to tylko przykład, zresztą archiwum ma tylko 100MB tworzy się w parę sekund) archiwum się nie tworzy - w mailach roota widać m.in. typowe problemy z interpretacją poleceń poszczególnych linii skryptu tj. '....file/command not found'.
Zrobiłem więc skrypt pomocniczy w którym najpierw wchodzę do folderu ze skryptem a potem odpalam go bezpośrednio czyli np.

#!/bin/sh
cd /srv/jboss_std/AdmNarz
./backup_create.sh

Teoretycznie coś się zaczęło dziać tj. utworzył katalog itp, w logach niby błędów nie było ale pliku archiwum brak. No i teraz najciekawsze... Po jakimś czasie cron przestał wykonywać jakiekolwiek zadania umieszczone w /etc/crontab...
Ktoś potem próbował coś mieszać z uprawnieniami do w/w tabeli - widziałem wpis chmod +rwx /etc/crontab (jakby to miało jakiś sens...). crontab jest teraz cały czas oflagowany jako wykonywalny ale nadal nie działa.
Kombinowałem już trochę - podmieniałem crontaba z nowo postawionej dystrybucji SLES'a, kopiowałem crontaba z innego serwera - bez zmian. Nie odpala się i koniec. Wyłączałem/włączałem crona ponownie - też bez zmian.

# /etc/init.d/crond stop
# /etc/init.d/crond start
# ps ax | grep cron

Zresztą chyba w jakiś cudowny sposób przechowywane są jeszcze gdzieś informacje o crontabie, bo po usunięciu obu plików crontab i ~crontab i założeniu pustych np geditem - znowu pojawiają się z atrybutami +rwx....

Chciałem spróbować jeszcze czy da się uruchomić coś z tabel crona konkretnego usera. Założyłem nową tabelę dla roota

# crontab -e

Wklepałem tam jakieś proste polecenie:

SHELL=/bin/bash
USER=root
*/1 * * * * echo "blablabla" >> /home/test2.txt

Taki wpis niby działa, ale znów nie ma możliwości uruchomienia skryptu kopii zapasowej (nawet nie zakłada katalogu).
Zrobiłem trochę 'trudniejsze' zadanie - w tabeli roota kazałem wykonać prosty skrypt odwołujący się do daty:

#!/bin/bash
data=$(date '+%Y-%m-%d')
godzina=$(date '+%H:%M:%S')
echo "test_wykonano: "$data.$godzina >> /home/test2.txt

...i tu już się zaczął wykładać m.in. niezrozumiałymi poleceniami 'date'. (Skrypt odpalany z palca działa).

1) W jaki sposób przywrócić główną tabelę 'crontab' do stanu funkcjonalności?
2) Jak wymusić (jeśli się da) wykonywanie przez crona bardziej 'skomplikowanych' skryptów z masą zmiennych, odwołań itp.
3) Jakieś inne wskazówki/sugestie ?