Czas, Informatyka, Linux, Linux - Podręcznik


CZAS

Odczytujemy i ustawiamy czas systemowy (date)

$ date

Sun Apr 18 10:40:07 CEST 1999

[crasz1@crash crash1]$ date -u

Sun Apr 18 08:40:58 UTC 1999

[crasz1@crash crash1]$ date -R

Sun, 18 Apr 1999 10:41:57 +0200

[crasz1@crash crash1]$ _

Opiszemy pierwszy odczyt czasu systemowego. Jest niedziela (Sun) 18 kwietnia (Apr) 1999 roku, godzina dziesiąta czterdzieści i siedem sekund. Skrót CEST oznacza wschodnioeuropejską strefę czasową, gdyż w Polsce panuje czas letni.
Następny odczyt (opcja -u) pokazuje czas systemowy przeliczany do uniwersalnego skoordynowanego (UTC). Jak łatwo zauważyć, powstał on przez odjęcie dwóch godzin, gdyż mamy czas letni.
Trzeci odczyt (opcja -R) podaje datę w formie zalecanym przez dokument RFC-882. Podawany jest tu czas lokalny w formacie do jakiego jesteśmy przyzwyczajeni. Natomiast zapis "+0200" określa przesunięcie czasowe względem UTC. W tym przypadku plus dwie godziny zero minut.

Spróbujmy teraz zmienić czas systemowy, tak abyśmy znaleźli się okresie czasu zimowego, czyli powiedzmy na 15 stycznia 1999 godzina 10:40

$ date 0115104099

date: cannot set date: Operation not permitted

Fri Jan 15 10:40:00 CET 1999

[crasz1@crash crash1]$ date

Sun Apr 18 11:55:07 CEST 1999

[crasz1@crash crash1]$ _

Jak widać, zwykli użytkownicy nie mają uprawnień do manipulowania czasem. Powtórzmy to tym razem jako root:

# date 0115104099

Fri Jan 15 10:40:00 CET 1999

[root@crash /root]# date -u

Fri Jan 15 09:41:34 UTC 1999

[crasz1@crash /root]# date -R

Fri, 15 Jan 1999 10:41:40 +0100

[root@crash /root]# shutdown -r now

Red Hat Linux relase 5.2 (Apollo)

Kernel 2.2.16 on an i586

crash login: root

Password:

Last login: Sun Apr 18 10:20:34 om tty2

[root@crash /root]# date

Sun Apr 18 10:55:37 CEST 1999

[root@crash /root]# _

Jak się przekonaliśmy zmiana czasu systemowego zachowuje swoją ważność do zamknięcia systemu. Aby była trwała musimy zmodyfikować ustawienia zegara sprzętowego.
Skrót CER oznacza środkowoeuropejską strefę czasową (czas zimowy w Polsce).
Pełny format polecenia zmieniającego czas systemowy jest następujący:

date MMDDhhmmCCYY.ss

gdzie:
MM - miesiąc (np. styczeń 01)
DD - dzień miesiąca (np. 15)
hh - godzina (np. 10)
mm - minuta (np. 40)
CC - pierwsze dwie cyfry roku (opcjonalnie system przyjmuje domyślnie te z aktualniej daty; tutaj 19)
CC - dwie ostatnie cyfry roku (opcjonalnie system przyjmuje domyślnie te z aktualniej daty; tutaj 99)
ss - sekundy (opcjonalnie system przyjmuje domyślnie 00)

Wykorzystajmy teraz pełny format i zmieńmy czas systemowy na 14 marca 1999 godzina 11:05 i 17 sekund, a następnie powróćmy korzystając ze skróconego formatu do czasu aktualnego:

# date

Sun Apr 18 11:42:40 CEST 1999

[root@crash /root]# date 031411051999.17

Sun Mar 14 11:05:17 CET 1999

[root@crash /root]# date 04181143

Sun Apr 18 11:43:00 CEST 1999

[root@crash /root]# _

Odczytujemy i ustawiamy zegar sprzętowy RTC (hwclock)

Jak łatwo się domyślić odczyt zegara sprzętowego przeprowadza się następująco:

# hwclock

Sun Apr 18 12:49:49 1999 -0.54325 seconds

[root@crash /root]# _

Zmieńmy teraz nieco czas systemowy, a następnie zsynchronizujmy do niego zegar sprzętowy:

# date

Sun Apr 18 12:52:24 CEST 1999

[root@crash /root]# date 04181330

Sun Apr 18 13:30:00 CEST 1999

[root@crash /root]# hwclock --systohc

[root@crash /root]# hwclock

Sun Apr 18 13:30:31 1999 -0.419225 seconds

[root@crash /root]# _

Zmieniliśmy czas systemowy, ale jednocześnie zapewniliśmy sobie przez równoczesną modyfikację nastaw zegara sprzętowego trwałość zmiany czasu systemowego.
Zapamiętajmy dobrze opcję --systohc (system time to hardware clock). Jest ona niezwykle skuteczna.
Spróbujmy teraz niezależnie zmienić czas zegara sprzętowego i zobaczyć jakie będą tego konsekwencje. Datę pozostawiamy bez zmian, zmienimy tylko godzinę i minutę:

[root@crash /root]# hwclock

Sun Apr 18 13:45:58 1999 -0.583225 seconds

[root@crash /root]# hwclock --set -date"04/18/99 14:15:00"

[root@crash /root]# hwclock

Sun Apr 18 14:15:06 1999 -0.090563 seconds

[root@crash /root]# date

Sun Apr 18 13:47:29 CEST 1999

[root@crash /root]# _

Zauważamy, że zmiana czasu zegara sprzętowego nie zrobiła żadnego wrażenia na czasie systemowym. Nie ma w tym nic dziwnego, gdyż oba zegary kontaktują się ze sobą tylko w momencie startu systemu.
Zrestartujmy teraz komputer.

[root@crash /root]# date

Sun Apr 18 14:31:56 CEST 1999

[root@crash /root]# hwclock

Sun Apr 18 14:32:06 1999 -0.090563 seconds

[root@crash /root]# _

Jak widzimy, czas systemowy został zsynchronizowany do zegara sprzętowego. Ten sam efekt możemy uzyskać w bardziej elegancki sposób, korzystając z opcji --hctosys (hardware clock to system time) polecenia hwclock:

[root@crash /root]# hwclock

Sun Apr 18 15:22:01 1999 -0.390563 seconds

[root@crash /root]# hwclock --set -date"04/18/99 17:50:00"

[root@crash /root]# hwclock

Sun Apr 18 17:50:11 1999 -0.820563 seconds

[root@crash /root]# date

Sun Apr 18 15:23:56 CEST 1999

[root@crash /root]# hwclock --hctosys

[root@crash /root]# date

Sun Apr 18 17:50:43 CEST 1999

[root@crash /root]# _

Najczęściej spotykaną w praktyce sytuacją jest konieczność trwałej korekty czasu o godzinę czy kilkanaście minut. Najłatwiejsza do zapamiętania sekwencja służąca do tego, to:

# date MMDDhhmm

# hwclock --systohc

Konfigurujemy parametry czasu (timeconfig)

Pozostały jeszcze dwa parametry czasu, nad którymi nie potrafimy sprawować kontroli. Mianowicie nie potrafimy zmienić strefy czasowej, ani określić, czy zegar sprzętowy odmierza czas UTC, czy też lokalny.
Otóż zegar sprzętowy odmierza jedynie czas od zadanego momentu początkowego i nie zawiera żadnych wskaźników dotyczących, czy jest to czas lokalny, czy UTC (ani tym bardziej jaka to strefa czasowa itp.).
To, jaki czas zawiera nasz zegar sprzętowy jest kwestią konwencji którą sami przyjmiemy.
Informacje o tej konwencji przechowuje plik /etc/sysconfig/clock. Natomiast informację na temat strefy czasowej plik /etc/localtime. Obejrzymy pierwszy z nich:

# cat /etc/sysconfig/clock

UTC=false

ARC=false

[root@crash /root]# _

Plik zawiera dwa parametry: UTC i ARC. Przyjmowane przez nie wartości oznaczają:
UTC=true - zegar sprzętowy zawiera czas UTC (GMT)
UTC=false - zegar sprzętowy zawiera czas lokalny
ARC=true - sprzętowy format czasu dla platformy Alpha
ARC=false - sprzętowy format czasu dla platformy Intel (nasza)

Plik /etc/localtime jest dowiązaniem symbolicznym do pliku Warsaw wskazującego "nasze miejsce na Ziemi".
Plik Warsaw nie jest zwykłym plikiem tekstowym. Zawiera on dane dotyczące nie tylko geograficznej strefy czasowej, ale także reguł zmiany czasu z letniego na zimowy (i odwrotnie) w naszym kraju.
Do modyfikacji plików /etc/localtime i /etc/sysconfig/clock służy narzędzie timeconfig. Wywołując:

#timeconfig

otrzymujemy semigraficzne menu, w którym możemy ustawić konwencję UTC (GMT) dla zegara sprzętowego (gwiazdka w polu [*] Hardware clock set to GMT) oraz wybrać miejsce na Ziemi (strefę czasową).

Skrypt setclock

W katalogu /usr/sbin znajdować się powinien skrypt setclock synchronizujący zegar sprzętowy do czasu systemowego z uwzględnieniem zawartości pliku /etc/sysconfig/clock.

# setclock

# date

Thu Apr 22 22:25:47 CEST 1999

[root@crash /root]# hwclock

Thu Apr 22 22:25:47 1999 -0.216723 seconds

[root@crash /root]# _

Skrypt setclock poprzez uwzględnienie ustawienia parametru "UTC=true/false" jest zatem bardzo wygodnym narzzędziem do synchronizacji zegara sprzętowego.
Należy ujawnić, że istnieje opcja --utc polecenia hwclock, wskazująca, ze przyjmujemy konwencję, iż zegar sprzętowy zawiera czas UTC.

Zlecenia jednorazowe (at)

Wykorzystajmy teraz pełny format i zmieńmy czas systemowy na 14 marca 1999 godzina 11:05 i 17 sekund, a następnie powróćmy korzystając ze skróconego formatu do czasu aktualnego:

# date

Sun Apr 18 11:42:40 CEST 1999

[root@crash /root]# date 031411051999.17

Sun Mar 14 11:05:17 CET 1999

[root@crash /root]# date 04181143

Sun Apr 18 11:43:00 CEST 1999

[root@crash /root]# _

Odczytujemy i ustawiamy zegar sprzętowy RTC (hwclock)

Jak łatwo się domyślić odczyt zegara sprzętowego przeprowadza się następująco:

# hwclock

Sun Apr 18 12:49:49 1999 -0.54325 seconds

[root@crash /root]# _

Zmieńmy teraz nieco czas systemowy, a następnie zsynchronizujmy do niego zegar sprzętowy:

# date

Sun Apr 18 12:52:24 CEST 1999

[root@crash /root]# date 04181330

Sun Apr 18 13:30:00 CEST 1999

[root@crash /root]# hwclock --systohc

[root@crash /root]# hwclock

Sun Apr 18 13:30:31 1999 -0.419225 seconds

[root@crash /root]# _

Zmieniliśmy czas systemowy, ale jednocześnie zapewniliśmy sobie przez równoczesną modyfikację nastaw zegara sprzętowego trwałość zmiany czasu systemowego.
Zapamiętajmy dobrze opcję --systohc (system time to hardware clock). Jest ona niezwykle skuteczna.
Spróbujmy teraz niezależnie zmienić czas zegara sprzętowego i zobaczyć jakie będą tego konsekwencje. Datę pozostawiamy bez zmian, zmienimy tylko godzinę i minutę:

[root@crash /root]# hwclock

Sun Apr 18 13:45:58 1999 -0.583225 seconds

[root@crash /root]# hwclock --set -date"04/18/99 14:15:00"

[root@crash /root]# hwclock

Sun Apr 18 14:15:06 1999 -0.090563 seconds

[root@crash /root]# date

Sun Apr 18 13:47:29 CEST 1999

[root@crash /root]# _

Zauważamy, że zmiana czasu zegara sprzętowego nie zrobiła żadnego wrażenia na czasie systemowym. Nie ma w tym nic dziwnego, gdyż oba zegary kontaktują się ze sobą tylko w momencie startu systemu.
Zrestartujmy teraz komputer.

[root@crash /root]# date

Sun Apr 18 14:31:56 CEST 1999

[root@crash /root]# hwclock

Sun Apr 18 14:32:06 1999 -0.090563 seconds

[root@crash /root]# _

Jak widzimy, czas systemowy został zsynchronizowany do zegara sprzętowego. Ten sam efekt możemy uzyskać w bardziej elegancki sposób, korzystając z opcji --hctosys (hardware clock to system time) polecenia hwclock:

[root@crash /root]# hwclock

Sun Apr 18 15:22:01 1999 -0.390563 seconds

[root@crash /root]# hwclock --set -date"04/18/99 17:50:00"

[root@crash /root]# hwclock

Sun Apr 18 17:50:11 1999 -0.820563 seconds

[root@crash /root]# date

Sun Apr 18 15:23:56 CEST 1999

[root@crash /root]# hwclock --hctosys

[root@crash /root]# date

Sun Apr 18 17:50:43 CEST 1999

[root@crash /root]# _

Najczęściej spotykaną w praktyce sytuacją jest konieczność trwałej korekty czasu o godzinę czy kilkanaście minut. Najłatwiejsza do zapamiętania sekwencja służąca do tego, to:

# date MMDDhhmm

# hwclock --systohc

Konfigurujemy parametry czasu (timeconfig)

Pozostały jeszcze dwa parametry czasu, nad którymi nie potrafimy sprawować kontroli. Mianowicie nie potrafimy zmienić strefy czasowej, ani określić, czy zegar sprzętowy odmierza czas UTC, czy też lokalny.
Otóż zegar sprzętowy odmierza jedynie czas od zadanego momentu początkowego i nie zawiera żadnych wskaźników dotyczących, czy jest to czas lokalny, czy UTC (ani tym bardziej jaka to strefa czasowa itp.).
To, jaki czas zawiera nasz zegar sprzętowy jest kwestią konwencji którą sami przyjmiemy.
Informacje o tej konwencji przechowuje plik /etc/sysconfig/clock. Natomiast informację na temat strefy czasowej plik /etc/localtime. Obejrzymy pierwszy z nich:

# cat /etc/sysconfig/clock

UTC=false

ARC=false

[root@crash /root]# _

Plik zawiera dwa parametry: UTC i ARC. Przyjmowane przez nie wartości oznaczają:
UTC=true - zegar sprzętowy zawiera czas UTC (GMT)
UTC=false - zegar sprzętowy zawiera czas lokalny
ARC=true - sprzętowy format czasu dla platformy Alpha
ARC=false - sprzętowy format czasu dla platformy Intel (nasza)

Plik /etc/localtime jest dowiązaniem symbolicznym do pliku Warsaw wskazującego "nasze miejsce na Ziemi".
Plik Warsaw nie jest zwykłym plikiem tekstowym. Zawiera on dane dotyczące nie tylko geograficznej strefy czasowej, ale także reguł zmiany czasu z letniego na zimowy (i odwrotnie) w naszym kraju.
Do modyfikacji plików /etc/localtime i /etc/sysconfig/clock służy narzędzie timeconfig. Wywołując:

#timeconfig

otrzymujemy semigraficzne menu, w którym możemy ustawić konwencję UTC (GMT) dla zegara sprzętowego (gwiazdka w polu [*] Hardware clock set to GMT) oraz wybrać miejsce na Ziemi (strefę czasową).

Skrypt setclock

W katalogu /usr/sbin znajdować się powinien skrypt setclock synchronizujący zegar sprzętowy do czasu systemowego z uwzględnieniem zawartości pliku /etc/sysconfig/clock.

# setclock

# date

Thu Apr 22 22:25:47 CEST 1999

[root@crash /root]# hwclock

Thu Apr 22 22:25:47 1999 -0.216723 seconds

[root@crash /root]# _

Skrypt setclock poprzez uwzględnienie ustawienia parametru "UTC=true/false" jest zatem bardzo wygodnym narzędziem do synchronizacji zegara sprzętowego.
Należy ujawnić, że istnieje opcja --utc polecenia hwclock, wskazująca, ze przyjmujemy konwencję, iż zegar sprzętowy zawiera czas UTC.

Zlecenia jednorazowe (at)

Użytkownik systemu Linux może uwolnić się od pamiętania o wykonaniu określonych czynności w systemie - składając zlecenie jednorazowe bądź stałe, np. przykład codziennego archiwizowania określonego katalogu o godz. 20.00.
Tego rodzaju zlecenia wnika obsługiwane są przez dwa demony. Zlecenia jednorazowe obsługuje demon atd, a zlecenia stałe demon crond.
Zlecenia użytkownik składa w postaci utworzonych odpowiednich plików tekstowych. Pliki do zlecenia jednorazowego tworzymy poleceniem at, a do zlecenia stałego poleceniem crontab. Demony atd i crond informują o wykonaniu zadań wysyłając list elektroniczny. Przesłanie emaila do użytkownika polega na skopiowaniu pliku tekstowego do odpowiedniego katalogu.

$ at 12:00

at> ls / > list, [Enter]

at> [Ctrl]+[d]

at>

warning: command will be executed using /bin/sh

job 3 at 1999-06-06 12:00

[crash1@linux crash1]$ atq

3 1999-06-06 12:00 a

[crash1@linux crash1]$ _

Zleciliśmy (at 12:00) wykonanie o godzinie 12:00 polecenia ls / > list. Polecenia at otwiera na standardowym wejściu plik, do którego wpisujemy polecenia do wykonania. Plik zamykamy wprowadzając znak końca pliku ([Ctrl]+[d]) wypisywany na ekranie jako (End Of Text). Nasze polecenie otrzymało numer 3 (job 3). Listę zleceń do wykonania możemy obejrzeć dzięki poleceniu atq. Pokazywane są tylko te zlecenia, które nie zostały jeszcze wykonane. Lista ta podzielona jest na kolejki oznaczone literami a do z i A do Z. Kolejką domyślną jest a. Ma ona najwyższy priorytet. Możemy przydzielić zadanie do innej kolejki (posługując się opcją -q).
Moment czasowy wykonania zadania może być określany w najrozmaitszych formatach. Wymieńmy kilka z nich:
hh:mm - godzina i minuta dnia dzisiejszego hh:mm DD.MM.YY - godzina i minuta w określonym dniu roku now + liczba jednostki - określa, za jaką liczbę jednostek czasu będzie wykonane polecenie. Dostępne jednostki czasu to:

minutes (minuty)

hours (godziny)

days (dni)

weeks (tygodnie)



Gdy minęła już 12:00 możemy sprawdzić, czy zostało wykonane nasze zadanie:

$ atq

[crash1@linux crash1]$ cat lista

bin

boot

...

...

usr

var

[crash1@linux crash1]$ _

Teraz utworzymy kilka kolejek i zażyczymy sobie potwierdzenia wykonania zadania:

$ at 12:30

at> ls / > list1, [Ctrl]+[d], [Ctrl]+[d]

warning: command will be executed using /bin/sh

job 4 at 1999-06-06 12:30

[crash1@linux crash1]$$ at 12:31 06.06.99

at> ls -F /, [Ctrl]+[d], [Ctrl]+[d]

warning: command will be executed using /bin/sh

job 5 at 1999-06-06 12:31

[crash1@linux crash1]$$ at now + 5 minutes

at> ls -F / > list2, [Ctrl]+[d], [Ctrl]+[d]

warning: command will be executed using /bin/sh

job 6 at 1999-06-06 12:17

[crash1@linux crash1]$$ at -mq b now +10 minutes

at> ls -F /, [Ctrl]+[d], [Ctrl]+[d]

warning: command will be executed using /bin/sh

job 7 at 1999-06-06 12:17

[crash1@linux crash1]$ atq

4 1999-06-06 12:30 a

5 1999-06-06 12:31 a

6 1999-06-06 12:17 a

7 1999-06-06 12:22 b

[crash1@linux crash1]$ atrm 5

[crash1@linux crash1]$ atq

4 1999-06-06 12:30 a

6 1999-06-06 12:17 a

7 1999-06-06 12:22 b

[crash1@linux crash1]$ _

Zobaczyliśmy różne formaty określenia momentu czasu wykonania. W ostatnim zleceniu (job 7) zażyczyliśmy sobie poinformowania nas (opcja -m) emailem o wykonaniu zadania oraz (-q b) wstawiliśmy zlecenie do kolejki b. Poznaliśmy też nowe polecenie usuwające zlecenia (atrm).
Gdy mineła już 12:30, możemy sprawdzić rezultat:

$ ls -F

bin/ kat2/ lista lista1 lista2 lista3

You have new mail in /var/spool/mail/crash1

[crash1@linux crash1]$ mail

Mail version 8.1 6/6/93. Type ? for help.

"/var/spool/mail/crash1: 1 message 1 new

>N 1 crash1@localhost Sun Jul 6 12:22 10/356 "Output from your job"

& [Enter]

Message: 1

>From crash1 Sun Jun 12:22:01 1999

Date: Sun, 6 Jun 1999 12:22:01 +0200

From: crash1@localhost

Subject: Output from jour job

q [Enter]

Saved 1 message in mbox

[crash1@linux crash1]$ _

Komunikat You have new mail .. poinformował nas, że mamy nową pocztę. Do czytania wiadomości użyliśmy standardowego programu mail.
Otrzymaliśmy wiadomość pustą, ale pamiętamy, że przełączyliśmy standardowe wyjście do pliku i nie było żadnych błędów. Wykonajmy jeszcze jedno ćwiczenie:

[crash1@linux crash1]$$ at now + 3 days

at> ls /, [Ctrl]+[d], [Ctrl]+[d]

warning: command will be executed using /bin/sh

job 8 at 1999-06-06 13:04

[crash1@linux crash1]$$ at 12:31 26.06.99

at> ls, [Ctrl]+[d], [Ctrl]+[d]

warning: command will be executed using /bin/sh

job 9 at 1999-06-06 12:31

[crash1@linux crash1]$$ at -m now + 3 minutes

at> ls /root > lista5, [Ctrl]+[d], [Ctrl]+[d]

warning: command will be executed using /bin/sh

job 10 at 1999-06-06 13:11

[crash1@linux crash1]$ atq

8 1999-06-09 13:04 a

9 1999-06-26 12:31 a

10 1999-06-06 13:11 a

[crash1@linux crash1]$ _

Założyliśmy dwa odległe w czasie zlecenia (job 8 i 9) i jedno bliskie (job 10). W tym ostatnim (ls /root) zażyczyliśmy sobie (-m) przesłania informacji o realizacji emailem. Gdy minie 13:11, to:

$ atq

8 1999-06-09 13:04 a

9 1999-06-26 12:31 a

[crash1@linux crash1]$ ls -F

bin/ kat2/ lista lista1 lista2 lista3 lista5 mbox

You have new mail in /var/spool/mail/crash1

[crash1@linux crash1]$ cat lista5

[crash1@linux crash1]$ mail

Mail version 8.1 6/6/93. Type ? for help.

"/var/spool/mail/crash1: 1 message 1 new

>N 1 crash1@localhost Sun Jul 6 13:11 12/386 "Output from your job"

& [Enter]

Message: 1

>From crash1 Sun Jun 13:11:00 1999

Date: Sun, 6 Jun 1999 13:11:00 +0200

From: crash1@localhost

Subject: Output from jour job

ls: /root: Permission denied

q [Enter]

Saved 1 message in mbox

[crash1@linux crash1]$ rm lista*

[crash1@linux crash1]$ _

Plik lista5 okazał się być pustym, czyli coś nie poszło jak należy. Wystarczy otworzyć wiadomość aby znaleźć tam komunikat o błędzie (Permission denied). Dlatego iż użytkownik crash1 nie ma żadnych praw dostępu do katalogu /root.

Przejdźmy teraz na drugą konsolę wirtualną i zalogujmy się jako użytkownik root:

# atq

8 1999-06-09 13:04 a

9 1999-06-26 12:31 a

[root@crash root]# ls /var/spool/at

a0000900ec9c77 spool

[root@crash root]# atrm 8

[root@crash root]# ls /var/spool/at

a0000800ec3cf8 a0000900ec9c77 spool

[root@crash root]# atrm 9

[root@crash root]# ls /var/spool/at

spool

[root@crash root]# atq

[root@crash root]# _

Teraz już wiemy, gdzie przechowywane są nasze zlecenia. Pliki a0000* są tekstowe i możemy obejrzeć ich zawartość.

# cat /etc/at.deny

[root@crash root]# _

Plik konfiguracyjny /etc/at.deny jest pusty. Oznacza to, że wszyscy użytkownicy systemu mogą używać poleceń at. Użytkownicy pozbawieni tego prawa powinni być umieszczeni w tym pliku. Plik /etc/at.deny jest istotny jeśli nie istnieje plik /etc/at.allow. Plik ten odwrotnie niż at.deny, wymaga jawnego wpisania użytkowników mających prawo do korzystania z polecenia at. Jeżeli także plik /etc/at.deny nie istnieje, to tylko root może korzystać z demona atd.
Na zakończenie warto zwrócić uwagę, że można sobie wcześniej przygotować plik tekstowy zawierający polecenia do wykonania (plik_z_poleceniami) i przekazać go jako zlecenie do realizacji w określonym czasie, korzystając z przełączenia standardowego wejścia:

at 12:30 < plil_z_poleceniami

albo z opcji -f:

at 12:30 -f plil_z_poleceniami

Zlecenia stałe (crontab)

Każdy użytkownik może założyć własną tabelę opisującą zlecenia stałe dla demona crontab. Założenie tabeli oznacza utworzenie odpowiedniego pliku tekstowego w katalogu /var/spool/cron. Plik ten będzie nazwany nazwą użytkownika. Do założenia, usunięcia i modyfikacji tabeli służy polecenie crontab. Nie należy edytować tego pliku bezpośrednio - tabela bowiem po każdej zmianie musi być na nowo zainstalowana, co zapewnia crontab. Analogicznie jak dla at, w systemie możemy używać jednego z dwóch plików konfiguracyjnych /etc/cron.allow albo /etc/cron.deny.

$ crontab -l

no crontab for crash1

[crash1@linux crash1]$ crontab -

[Ctrl]+[d]

[crash1@linux crash1]$ crontab -l

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

# (- installed on Sun Jun 6 18:22:30 1999)

# (Cron version -- $ld: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)

[crash1@linux crash1]$ crontab -r

[crash1@linux crash1]$ crontab -l

no crontab for crash1

[crash1@linux crash1]$ touch nowy

[crash1@linux crash1]$ crontab nowy

[crash1@linux crash1]$ crontab -l

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

# (- installed on Sun Jun 6 18:24:30 1999)

# (Cron version -- $ld: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)

[crash1@linux crash1]$ crontab -e

/bin/sh: /usr/bin/vi: No such file or directory

crontab: "/usr/bin/vi:" exited with status 126

[crash1@linux crash1]$ rm nowy

[crash1@linux crash1]$ _

Plik (tabela) musi wcześniej istnieć i być sensownym z punktu widzenia polecenia crontab. Plik pusty jest także traktowany jako sensowny. Podając zamiast nazwy - (minus), czyli tak zwaną pseudonazwę pliku, spowodujemy otwarcie jako pliku standardowego wejścia (klawiatury). Polecenie crontab z punktu widzenia zwykłego użytkownika ma tylko trzy opcje:

-l - wypisywanie zawartości tablicy (list)

-r - usunięcie tabeli (remove)

-e - edycja tabeli (edit). Do edycji wykorzystywany jest domyślnie vi. Po opuszczeniu vi tabela zostaje automatycznie zapisana i zainstalowana

W naszym przypadku crontab oczekuje edytora vi w katalogu /usr/bin, ale niestety nie znajduje go tam. Przejdźmy zatem na drugą drugą konsolę wirtualną, gdzie zalogowany jest użytkownik root:

# which vi

/bin/vi

[root@crash root]# ln -s /bin/vi /usr/bin/vi

[root@crash root]# _

Znaleźliśmy vi i utworzyliśmy odpowiedni łącznik symboliczny, aby sprostać oczekiwaniom crontab-a. Teraz możemy przystąpić do edycji naszej tabeli.
Nasz plik będzie się składał z wierszy. Każdy wiersz uruchamia określone polecenie i podaje czas jego wykonania. Wiersz składa się z sześci pól oddzielonych od siebie spacjami. Ostatnie szóste pole zawiera polecenie do wykonaia. Pierwszych pięć pól określa momenty czasowe:

pierwsze pole - minutę (od 0 do 59)

drugie pole - godzinę (od 0 do 23)

trzecie pole - dzień miesiąca (od 1 do 31)

czwarte pole - miesiąc (od 1 do 12)

piąte pole - dzień tygodnia (od 0 do 7), przy czym 0 i 7 oznaczają tu niedziele, 1 poniedziałek itd.

Konkretna wartość w danym polu może być wpisana w jednym z następujących sposobów:

pojedyncza wartość - np. 23

zakres - dwie liczby rozdzielone znakiem minus, np. 11-25

lista - liczby (lub zakresy) oddzielone przecinkami (ale bez spacji), np. 1,5,12 albo 1-4,12-18

gwiazdka - oznacza przyjmowanie wszystkich wartości z zakresu odpowiadającego danemu polu, np. *


Dodatkowo stosowany może być zapis kroku, np. "/2" oznacza z krokiem dwa, czyli zapis "0-13/2" odpowiada zapisowi "0,2,4,6,8,10,12".

Przykładowo wiersz:

****poleceni1

oznacza wykonywanie co minutę polecenia polecenie1, a wiersz:

012**1polecenie2

oznacza wykonywanie w każdy poniedziałek o godzinie 12:00 polecenia poleceni2

$ crontab -e

[i], ***** date >> naszczas, [Enter], */10**** echo

"znowu 10 minut" >> naszczas, [Esc], :wq, [Enter]

"crontab.886" 2 lines, 75 characters written

crontab: installing new crontab

[crash1@linux crash1]$ crontab -l

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

# (/tmp/crontab.886 installed on Sun Jun 6 20:41:25 1999)

# (Cron version -- $ld: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)

*****date >> naszplik

*/10****echo"znowu 10 minut" >> naszczas

[crash1@linux crash1]$ _

Powyższe zapisy powodują utworzenie pliku naszczas i dopisywanie do niego co minutę daty systemowej, a co dziesięć minut tekstu "znowu 10 minut".
Po kilkunastu minutach możemy obejrzeć plik naszczas:

$ cat naszczas

Sun Jun 6 20:42:00 CEST 1999

...

...

Sun Jun 6 20:49:01 CEST 1999

znowu 10 minut

Sun Jun 6 20:50:01 CEST 1999

...

...

Sun Jun 6 20:59:00 CEST 1999

znowu 10 minut

Administrator (root) może tworzyć, modyfikować i usuwać tabele innych użytkowników korzystając z opcji -u (user) polecenia crontab. Przejdziemy teraz na pierwszą konsolę wirtualną i usuniemy tabelę crash1 użytkownika crash1:

# crontab -u crash1 -r

[root@crash root]# _

Obejrzyjmy teraz plik /etc/crontab. Jest to systemowa tabelka. Skojarzone są z nia katalogi /cron.daily, /cron.hourly, /cron.monthly, /cron.weekly zawierające skrypty uruchamiane w zadanym czasie (zgodnie z ich nazwami):

#cat /etc/crontab

SHELL=/bin/bash

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

MAILTO=root

# run parts

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

02 4*** root run-parts /etc/cron.daily

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

42 41** root run-parts /etc/cron.monthly

Pli /etc/crontab nie jest dostępny dla polecenia crontab. Edytujemy go bezpośrednio edytorem tekstowym. Zmiany wchodzą w życie natychmiast po zakończeniuedycji pliku. Jednakże nasz zakres ingerencji musi być ograniczony. Pole szóste ma inny format niż w typowej tabeli. Nas interesować będą tylko pola określające czas. Zauważmy, że domyślna zawartość /etc/crontab jest przygotowana dla maszyny pracującej non-stop (24 godziny na dobę), gdyż zadania dzienne, tygodniowe i miesięczne uruchamiane są o godzinie czwartejrano (z minutami). Dla całodobowego serwera jest to pora najmniejszego obciążenia. Zwykły komputer użytkowany w domu czy w biurze raczej nigdy o tej porze nie będzie włączony, zatem zlecone zadania mogą nigdy nie zostać wykonane (prez cały okres eksploatacji systemu!).
Warto zatem zmienić godziny uruchamiania tych zadań, tak aby były właściwe dla sposobu użytkowania naszego systemu. Edycji pliku /etc/crontab dokonujemy oczywiście jako root.

Każdy użytkownik może mieć jedną i tylko jedną tabelę. Przy istniejącej już tabeli podanie kolejnego pliku (nowy_plik) spowoduje nadpisanie zawartości tabeli treścią pliku nowy_plik (innymi słowy usunięcie starej tabeli i założenie nowej z treścią pliku nowy_pik).

Pauzujemy (sleep)

Pamiętamy pewnie z DOS-a polecenie PAUSE, bardzo użyteczne w skryptach. W Linuksie takim opóźnieniem czasowym jest polecenie sleep. Przykładowo:

# sleep 10s ; ls /

spowoduje odczekanie 10 sekund, po czym wykona następne polecenie (ls /). Pauza może być bardzo długa, gdyż dysponujemy następującymi jednostkami:

s - sekundy

m - minuty

h - godziny

d - dni

Sufiks określający jednostki czasu wpisujemy bezpośrednio za liczbą (nie możebyć pomiędzy nimi spacji).

1



Wyszukiwarka

Podobne podstrony:
Administracja, Informatyka, Linux, Linux - Podręcznik
RPM, Informatyka, Linux, Linux - Podręcznik
Prawa dostępu, Informatyka, Linux, Linux - Podręcznik
Strumienie, Informatyka, Linux, Linux - Podręcznik
Jądro i system plików, Informatyka, Linux, Linux - Podręcznik
Archiwa i łaty, Informatyka, Linux, Linux - Podręcznik
Sieć, Informatyka, Linux, Linux - Podręcznik
Katalogi i pliki, Informatyka, Linux, Linux - Podręcznik
Administracja, Informatyka, Linux, Linux - Podręcznik
RPM, Informatyka, Linux, Linux - Podręcznik
dokumentacja gentoo linux podręcznik gentoo linux M57EBYYUOP66AXNLPFQ2HEZPW72JOO2Z24YBSFI
linux, Technik Informatyk, Linux
Prezentacja krótka Informatyka Linux
Informatyka, Linux, Linux
oferta handlowa firmy informatycznej, Linux, płyty dvd, inne dvd, 2, Profesja, semestr 1
Linux Podręcznik?ministratora Sieci PL
dokumentacja gentoo linux podręcznik gentoo linux M57EBYYUOP66AXNLPFQ2HEZPW72JOO2Z24YBSFI
informatyka linux biblia ubuntu fedora debian i 15 innych dystrybucji christopher negus ebook

więcej podobnych podstron