Czy źle jest ręcznie edytować plik cron?


12

Zazwyczaj instruuje się go, aby wprowadzał nowe zadania crona za pomocą wiersza poleceń; ale łatwiej mi było (dzięki lepszej kontroli bieżących zadań crona) ręcznie edytować (w edytorze tekstów) plik crona użytkownika /var/spool/cron/crontabs/root.

Czy edytowanie pliku w edytorze tekstu jest niebezpieczne?

Komentarze w pliku domyślnym są mylące. Pierwsza linia mówi

# DO NOT EDIT THIS FILE - edit the master and reinstall.

Ale czwarta linia mówi

# Edit this file to introduce tasks to be run by cron.

2
Dlaczego nie po prostu umieścić rzeczy pod /etc/cron.d?
Zoredache

To może być dobry pomysł; ale nie miałem na myśli, który plik do edycji, porównuję edycję pliku według edytora lub uruchamiam polecenie crontab.
Googlebot

@Wszystko chyba jedyną różnicą jest sprawdzanie składni wykonane przez crontab-e. To tylko bufor tekstowy ze sprawdzaniem składni. Możesz także zmienić swój zwykły edytor, a crontab-e załaduje się do tego. Znaczenie xyntax polega na tym, że jeśli popełnisz błąd, cały plik zostanie zignorowany. Nawet jeśli korzystasz z zewnętrznego narzędzia, powinieneś użyć crontab-e do odczytu pliku i wysłać go z powrotem do crontab-e po zakończeniu. Dzięki temu nie musisz się już martwić składnią. Lepiej podzielić pliki od użytkownika i zadań systemowych, dlatego lepiej używać /etc/cron.d do zadań użytkownika / testów.
m3nda

Odpowiedzi:


22

Jeśli zmodyfikujesz plik użytkownika w crontabs, powinien on działać. Należy jednak wziąć pod uwagę dwie kwestie:

  1. Jeśli wpisałeś niepoprawnie wpis crona w pliku, nie zostaniesz ostrzeżony w przeciwieństwie do użycia crontab -epolecenia.
  2. Nie możesz edytować pliku użytkownika bezpośrednio w crontabs bez logowania jako root lub używając sudo. Otrzymasz błąd odmowy uprawnień.

Edytować

Jeszcze jeden punkt do dodania. Gdy edytujesz plik bezpośrednio, możesz zostać ostrzeżony przez edytor tekstu, jeśli otworzysz plik dwukrotnie (dwóch użytkowników uzyskuje dostęp do tego samego pliku). Jednak lista cronów zostanie zastąpiona przy użyciu crontab -ez dwóch różnych sesji powłoki tego samego użytkownika. To kolejna różnica.


bardzo subtelne punkty! Nigdy nie spotkałem się (nie znałem) z drugim problemem, ponieważ zawsze pracuję jako root.
Googlebot

4
Ponadto „nie edytuj” w pliku domyślnym jest spowodowane tym, że aktualizacja / ponowna instalacja może zastąpić ten plik.
Chris S

Nie wspomniałeś, że użytkownik, który edytuje crontab, bezpośrednio traci sprawdzanie santax, które crontab -ezapewnia.
Adam F,

1
@AdamF: O tym mówi punkt 1!
Khaled

8

Jeśli dobrze rozumiem, edytujesz plik ręcznie za pomocą edytora tekstu, ponieważ nie chcesz używać crontab -e. Domyślam się, że to dlatego, że używa vi jako edytora, a ty nie znasz go.

Zmieniasz crontab -e (i inne rzeczy, które wymagają edytora), aby używać bardziej znanego nano edytora, uruchamiając

export EDITOR=nano

przed

crontab -e

Możesz ustawić nano jako domyślny edytor, edytując plik ~ / .bash_profile, aby dołączyć go export EDITOR=nanona końcu.

Aby odpowiedzieć na pytanie, nie należy edytować pliku bezpośrednio, ponieważ może zostać zastąpiony bez Twojej wiedzy. Czwarta linia mówi, co jest napisane, ponieważ pochodzi ona z pliku crontab, który należy ręcznie edytować (powiedziałby to jako pierwszy wiersz).


Dziękuję za opisową odpowiedź. Jestem w pełni zaznajomiony z edytorem komend vi crontab; ale używam gedit (nie w terminalu ssh), ponieważ łączę się bezpośrednio z serwerem z pulpitu Linux.
Googlebot

Polecam również dodanie polecenia export EDITOR do pliku bashrc, aby uniknąć zapisywania go przy każdym logowaniu do ssh.
m3nda

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.