Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
Mam prośbę, jak skonstruować skrypt? O co chodzi, o jaką funkcjonalność?
Robię codzienną kopię borg backup kat. dom., która zapisywana jest na zewnętrznym nośniku - karcie pamięci. Obecnie działa to jako usługa systemowa crontab o stałej godzinie każdego dnia.. Wszystko dobrze dopóki uruchomię system przed zapodaną w crontab`ie godziną, bo jeżeli się spóźnię kopii tego dnia nie będzie.
Moje pytanie brzmi: jak napisać skrypt który uruchomi borgbackup np. o pierwszej pełnej godzinie jednokrotnie danego dnia obojętnie o jakiej porze dnia uruchomię komputer.
Ostatnio edytowany przez mark (2020-12-14 17:09:45)
Offline
Zrób sobie usługę systemd opartą o mechanizm timers. Jak usługa przegapi czas swojego startu, np z powodu wyłączenia maszyny albo hibernacji, to potem po uruchomieniu systemu zostanie automatycznie wywołana.
Ostatnio edytowany przez morfik (2020-12-05 18:00:20)
Offline
morfik napisał(-a):
Zrób sobie usługę systemd opartą o mechanizm timers. Jak usługa przegapi czas swojego startu, np z powodu wyłączenia maszyny albo hibernacji, to potem po uruchomieniu systemu zostanie automatycznie wywołana.
Tego przyznam nie znałem. Czyli tak: zostawić aktualną konfigurację w crontab i uruchomić usługę systemd?
Z tego co na prędce wyczytałem to muszę utworzyć plik np borgback.service w /usr/lib/systemd/system/borgback.service
[Unit] Description=MyTimer [Service] ExecStart=/bin/bash /path/to/borgback.sh
borgback.sh to skrypt uruchamiany obecnie przez crontab.
Sprawdziłem jeszcze usługi systemd
systemctl list-unit-files --type timer UNIT FILE STATE anacron.timer enabled apt-daily-upgrade.timer enabled apt-daily.timer enabled fstrim.timer disabled logrotate.timer enabled man-db.timer enabled systemd-tmpfiles-clean.timer static 7 unit files listed.
Jak powinien wyglądać plik borgback.timer aby spełniał powyższe kryteria?
Offline
mark napisał(-a):
Tego przyznam nie znałem. Czyli tak: zostawić aktualną konfigurację w crontab i uruchomić usługę systemd?
Bez crontab, tylko plik .service i .timer .
mark napisał(-a):
Z tego co na prędce wyczytałem to muszę utworzyć plik np borgback.service w /usr/lib/systemd/system/borgback.service
Nie w /usr/... tylko w /etc/ .
Plik .timer również w /etc/ . Jak te dwa pliki będą mieć taką samą nazwę (przed kropką) to wtedy timer automatycznie wywoła usługę .service.
mark napisał(-a):
Jak powinien wyglądać plik borgback.timer aby spełniał powyższe kryteria?
Trza było sobie podejrzeć te timery, które ci wyrzuciło (systemctl cat usluga.timer) — coś na wzór:
[Unit] Description=blablalba [Timer] OnCalendar=Sun *-*-* 03:10:00 RandomizedDelaySec=60 Persistent=true [Install] WantedBy=timers.target
Ostatnio edytowany przez morfik (2020-12-05 20:37:31)
Offline
morfik napisał(-a):
Trza było sobie podejrzeć te timery, które ci wyrzuciło (systemctl cat usluga.timer) — coś na wzór:
Mam tu dwa dla przykładu więc mogę wzorować się ma poniższych istniejących tylko wytłumacz mi proszę zasadę działania opcji "OnCalendar=..." oraz "RandomizeDelaySec=..."
Ja chciałbym aby borg wykonał swoją robotę o np. pełnej godzinie obojętnie o której uruchomię system lecz tylko jeden raz każdego dnia.
cat /etc/systemd/system/timers.target.wants/apt-daily.timer [Unit] Description=Daily apt download activities [Timer] OnCalendar=*-*-* 6,18:00 RandomizedDelaySec=12h Persistent=true cat /etc/systemd/system/timers.target.wants/anacron.timer [Unit] Description=Trigger anacron every hour [Timer] OnCalendar=*-*-* 07..23:30 RandomizedDelaySec=5m Persistent=true [Install] WantedBy=timers.target
Czy taka lokalizacja będzie właściwa?
touch /etc/systemd/system/multi-user.target.wants/borgback.service touch /etc/systemd/system/timers.target.wants/borgback.timer
Offline
Alternatywnie wykorzystać dedykowane ku temu narzędzie - anacron:
Anacron (jak "anac(h)ronistic" czyli "anachroniczny") jest programem planującym okresowe wykonywanie poleceń. Wykonuje zadania w przedziałach czasowych wyrażonych w dniach. W odróżnieniu do crona, Anacron nie zakłada, że system działa nieprzerwanie. Może być zatem używany do kontroli dziennego, tygodniowego i miesięcznego wykonywania zadań (lub jakiekogolwiek innego przedziału wyrażonego w dniach) w systemach, które nie działają 24 godziny na dobę. Poprawnie zainstalowany i skonfigurowany Anacron zadba o wykonanie zadań w oznaczonym terminie, gdy tylko pozwoli na to czas działania komputera.
Offline
mark napisał(-a):
wytłumacz mi proszę zasadę działania opcji "OnCalendar=..." oraz "RandomizeDelaySec=..."
Czas, który masz w OnCalendar masz rozpisany tutaj dokładnie. A RandomizedDelaySec to losowy czas między 0 a wartość, którą sobie ustawisz, by wywołać usługę. Czyli jak ustawisz godzinę 01:00:00 w nocy i dasz w RandomizedDelaySec wartość 60s, to z chwilą wybicia 01:00:00 system uruchomi tę usługę w czasie losowym od 0 do 60s. Czyli może uruchomić usługę o 01:00:00 lub 01:01:00 i w każdym czasie pomiędzy tymi dwoma godzinami. Bo wiele usług może być uruchamianych o konkretnej godzinie, i by ich nie uruchamiać jednocześnie, to taka dywersyfikacja czasu może się przydać, by rozłożyć obciążenie maszyny, przynajmniej ja to tak widzę. xD
mark napisał(-a):
Czy taka lokalizacja będzie właściwa?
Kod:
touch /etc/systemd/system/multi-user.target.wants/borgback.service touch /etc/systemd/system/timers.target.wants/borgback.timer
Nie. Oba pliki mają być w /etc/systemd/system/ . Jak włączysz .timer to odpowiednie linki potworzy ale same pliki mają być w tym katalogu. Usługa .service nie musi być przypisana nigdzie, bo jak .timer wybije, to automatycznie tę usługę aktywuje.
Ostatnio edytowany przez morfik (2020-12-05 23:02:15)
Offline
seler napisał(-a):
Alternatywnie wykorzystać dedykowane ku temu narzędzie - anacron:
Wydaje się że te narzędzie anacron jest mniej skomplikowane i bardziej odpowiada moim potrzebom. Chciałbym się teraz skupić, bez urazy morfik, właśnie na nim.
Offline
Tzn. oczywiście timery od systemd to też dedykowane narzędzie, ale dla "casualowego" użytkownika anacron może być prostszym rozwiązaniem :]
A poza tym fakt faktem, podstawę unitów systemd dobrze znać.
Ostatnio edytowany przez seler (2020-12-06 15:39:48)
Offline
morfik napisał(-a):
Nie ma prostszego rozwiązania niż .timer. xD
Skoro tak twierdzisz głupio byłoby Ciebie zignorować więc przygotowałem rozwiązanie tylko proszę o potwierdzenie czy dobrze kombinuję, ewentualną korektę. xD
1. Dla jasności pokażę skrypt umiejscowiony w moim kat.dom., którym wykonuje obecnie borg kopię backup.
#!/bin/sh NOW=$(date +"%d-%m") FILE="$NOW" borg create --compression zstd,15 --one-file-system --stats /media/marek/68..NR.UUID..20/backup/borg/::"$NOW" --patterns-from /home/marek/.skrypty/backup-home-file-list 2>> ~/.borg_log/"$NOW" && borg prune --list --stats --keep-last 8 /media/marek/68..NR.UUID..20/backup/borg/ && find /home/marek/.borg_log/* -maxdepth 1 -type f -ctime +8 -exec rm -rfv {} \;
2. Wyłączam obecne zadanie crona w /var/spool/cron/crontabs/marek ponieważ od tej chwili automatyzacją backup`u sterować będzie systemd.
3. W tym celu tworzę dwa pliki w /etc/systemd/system/borgback.service
echo "[Service] ExecStart=sh /home/marek/borgback.sh" > /etc/systemd/system/borgback.service
oraz /etc/systemd/system/borgback.timer
echo "[Unit] Description=Daily borg copy [Timer] OnCalendar=*-*-* 1,10:00 RandomizedDelaySec=12h Persistent=true" > /etc/systemd/system/borgback.timer
Funkcje timer`a rozumiem w ten sposób:
uruchomienie zadania codziennie o godzinie 10:00 z powtórzeniem co jedną godzinę (to w przypadku gdyby o tej godzinie nie nastąpiło uruchomienie komputera). Dalej funkcja RandomizedDelaySec=12h rozciąga tą gotowość na kolejne 12 godzin. Taki czas-okres ustaliłem o ile przedłużałoby się uruchomienie kompa.
Teraz o ile dobrze kombinuję powinno zadziałać czy nie? xD
Offline
Tylko wtrącę się offtopem, że dla czytelności długie polecenia w skryptach można złamać w miejscach spacji znakiem \ o ile nie robimy tego wewnątrz cytowań lub pomiędzy `` lub w środku $( )
Twój skrypt powinien działać identycznie w takiej o ile czytelniejszej postaci:
#!/bin/sh NOW=$(date +"%d-%m") FILE="$NOW" borg create --compression zstd,15 \ --one-file-system \ --stats /media/marek/68..NR.UUID..20/backup/borg/::"$NOW" \ --patterns-from /home/marek/.skrypty/backup-home-file-list 2>> ~/.borg_log/"$NOW" \ && borg prune --list \ --stats \ --keep-last 8 /media/marek/68..NR.UUID..20/backup/borg/ \ && find /home/marek/.borg_log/* \ -maxdepth 1 \ -type f \ -ctime +8 \ -exec rm -rfv {} \;
Ostatnio edytowany przez seler (2020-12-06 20:16:56)
Offline
seler napisał(-a):
Tylko wtrącę się offtopem, że dla czytelności długie polecenia w skryptach można złamać w miejscach spacji znakiem \ o ile nie robimy tego wewnątrz cytowań lub pomiędzy `` lub w środku $( )
Twój skrypt powinien działać identycznie w takiej o ile czytelniejszej postaci
O tak, bardzo Ci dziękuję za tę uwagę, masz absolutną rację: tak jest czytelniej! Człowiek się uczy całe życie a głupim jest ten, który nie korzysta z dobrych rad. Dzięki!
Offline
Tu masz przykład uruchamiania usługi via timer:
Plik .service
[Unit] Description=blabla ConditionACPower=true [Service] Type=oneshot ExecStart=/bin/.... SyslogIdentifier=borg-home
Plik .timer
[Unit] Description=blabla [Timer] OnCalendar=*-*-* 03:10:00 RandomizedDelaySec=60 Persistent=true [Install] WantedBy=timers.target
Potem włączasz timer via systemctl enable i to wszystko. Jak timer wybije, to ci te usługę w service uruchomi. No chyba, że laptop np. będzie na baterii, to wtedy nie uruchomi, bo tam jest warunek ConditionACPower=true, czyli by komp był podłączony do gniazdka, by czasem taki backup nie zeżarł baterii w najmniej oczekiwanym momencie. xD Backup jest uruchamiany o 3:10-3:11 w nocy, a jak wtedy komp nie działa, to system uruchomi ten backup tuż po starcie systemu, chyba też te 60s ale to trzeba by dokładnie wyczytać kiedy te timery są uruchamiane po starcie systemu, czy od razu czy z jakimś opóźnieniem. Jak chcesz ręcznie uruchomić backup, to wywołujesz usługę .service via systemctl start. I to cała filozofia. Potem sobie zobacz na systemct list-timers i masz tam listę co kiedy zostało uruchomione i kiedy zostanie uruchomione w przyszłości.
BTW tego twojego polecenia — co te find ma tam robić ?
Offline
morfik napisał(-a):
Potem włączasz timer via systemctl enable i to wszystko. Jak timer wybije, to ci te usługę w service uruchomi. No chyba, że laptop np. będzie na baterii, to wtedy nie uruchomi, bo tam jest warunek ConditionACPower=true, czyli by komp był podłączony do gniazdka, by czasem taki backup nie zeżarł baterii w najmniej oczekiwanym momencie. xD Backup jest uruchamiany o 3:10-3:11 w nocy, a jak wtedy komp nie działa, to system uruchomi ten backup tuż po starcie systemu, chyba też te 60s ale to trzeba by dokładnie wyczytać kiedy te timery są uruchamiane po starcie systemu, czy od razu czy z jakimś opóźnieniem. Jak chcesz ręcznie uruchomić backup, to wywołujesz usługę .service via systemctl start. I to cała filozofia. Potem sobie zobacz na systemct list-timers i masz tam listę co kiedy zostało uruchomione i kiedy zostanie uruchomione w przyszłości.
BTW tego twojego polecenia — co te find ma tam robić ?
Pliki wrzuciłem do /etc/systemd/system/
później z poniższym wynikiem:
# systemctl enable borgback.service The unit files have no installation config (WantedBy=, RequiredBy=, Also=, Alias= settings in the [Install] section, and DefaultInstance= for template units). This means they are not meant to be enabled using systemctl. Possible reasons for having this kind of units are: • A unit may be statically enabled by being symlinked from another unit's .wants/ or .requires/ directory. • A unit's purpose may be to act as a helper for some other unit which has a requirement dependency on it. • A unit may be started when needed via activation (socket, path, timer, D-Bus, udev, scripted systemctl call, ...). • In case of template units, the unit is meant to be enabled with some instance name specified.
Kopii nie zrobiło. Nie wiem, może to moja wina bo wcześniej nie zalogowałem karty pamięci w Thunar.
Dalej sprawdziłem to:
systemctl list-timers NEXT LEFT LAST PASSED Mon 2020-12-07 18:31:40 CET 1min 0s left Mon 2020-12-07 18:10:33 CET 20min ag Mon 2020-12-07 21:55:12 CET 3h 24min left Mon 2020-12-07 11:48:54 CET 6h ago Tue 2020-12-08 00:00:00 CET 5h 29min left Mon 2020-12-07 11:48:54 CET 6h ago Tue 2020-12-08 00:00:00 CET 5h 29min left Mon 2020-12-07 11:48:54 CET 6h ago Tue 2020-12-08 06:36:47 CET 12h left Mon 2020-12-07 11:48:54 CET 6h ago Tue 2020-12-08 18:25:43 CET 23h left Mon 2020-12-07 18:25:43 CET 4min 56s
faktycznie ostatnia pozycja pokrywa się z tym niespełnionym uruchomieniem. Zobaczę jutro jak zadziała.
Napisałeś też o tym warunku ConditionACPower=true, a gdzie on jest definiowany?
Pytasz o find w moim skrypcie. Jak widać ilość kopii borg ustaliłem na 8, tyle powinno wystarczyć. Każda kopia posiada także swój log dlatego find wyszukuje i pozostawia 8 ostatnich a reszta (dziewiąty najstarszy) jest usuwany.
borg prune --list \ --stats \ --keep-last 8 /media/marek/68..NR.UUID..20/backup/borg/ \ && find /home/marek/.borg_log/* \ -maxdepth 1 \ -type f \ -ctime +8 \ -exec rm -rfv {} \;
Offline
Mówiłem, włącz tylko .timer. Ta usługa .service nie ma być startowana z systemem (tak jak usługi systemowe) — ona ma być uruchamiana w konkretnym czasie wskazanym przez .timer. Dlatego włączasz tylko .timer.
Używaj w poleceniach z systemd wyjścia długiego (systemctl list-timers -l --no-pager), bo on standardowo obcina długie linijki (chowa jest pagerze).
ConditionACPower=true jest w pliku usługi, podałem ci oba pliki.
Co do find, to cron ci nie mailuje wyników backup'u? Ja dostaje taki komunikat na mail'a (mam skrzynkę root'a podpiętą pod thunderbird):
Offline
morfik napisał(-a):
Mówiłem, włącz tylko .timer. Ta usługa .service nie ma być startowana z systemem (tak jak usługi systemowe) — ona ma być uruchamiana w konkretnym czasie wskazanym przez .timer.
Tak teraz widzę że w ten sposób sugerowałeś a ja nie wiedząc dlaczego zasugerowałem się .service (tak jak normalną usługą). Już to koryguję.
A co do logów - można logować mail`em przez root`a ale po co? Wydaje mi się że mój sposób jest prostszy, nie zaśmieca mi skrzynki pocztowej i, nie angażuje root`a (bo i po co)? Jutro się okaże jak ten sposób działa. Dam znać. xD
Offline
No taki standard logowania cron'a, że on wrzuca cokolwiek się pojawi na terminalu podczas pracy uruchamianej usługi w mail i wysyła do root, Potem można te maile podejrzeć na terminalu via polecenie mail. Ja mam dodatkowo przekierowanie poczty root'a na swojego zwykłego usera i jego plik z pocztą mam podpięty pod thunderbird (osobne konto, mail widać jaką ma formę na obrazku wyżej xD), co ułatwia nieco przeglądanie poczty. xD Inne usługi również mailują do root'a sporo. Jak sobie przepniesz usługę pod systemd, to on się będzie zajmował logami. Tak czy inaczej osobne logowanie i ogarnianie go jest zbędne trochę zarówno przy cron jak i systemd. xD
Ostatnio edytowany przez morfik (2020-12-07 20:45:34)
Offline
Czy tak jest prawidłowo?
sudo systemctl enable borgback.timer Created symlink /etc/systemd/system/timers.target.wants/borgback.timer → /etc/systemd/system/borgback.timer. [marek@marek ~]$ systemctl status borgback.timer ● borgback.timer - Daily_borg_backup Loaded: loaded (/etc/systemd/system/borgback.timer; enabled; vendor preset: e Active: inactive (dead) Trigger: n/a
inactive?
Offline
No generalnie dałeś tylko enable. Więc timer jeszcze nie działa ale zacznie działać po restarcie systemu. Jeśli chcesz by zaczął działać od razu to jeszcze musisz go wystartować -- tak jak z normalną usługą dajesz systemctl start .timer .
Offline
morfik napisał(-a):
No generalnie dałeś tylko enable. Więc timer jeszcze nie działa ale zacznie działać po restarcie systemu. Jeśli chcesz by zaczął działać od razu to jeszcze musisz go wystartować — tak jak z normalną usługą dajesz systemctl start .timer .
Dzisiaj sprawdzam i wyszło że nie zadziałało. Mam w pliku .timer zdeklarowany czas aktywacji po włączeniu kompa 180s. Odczekałem ponad 3 minuty bo żaden log się nie pojawił a następnie odpaliłem ręcznie, tak jak zalecałeś, tzn.
# systemctl status borgback.timer ● borgback.timer - Daily_borg_backup Loaded: loaded (/etc/systemd/system/borgback.timer; enabled; vendor preset: e Active: active (waiting) since Tue 2020-12-08 17:20:13 CET; 10min ago Trigger: Wed 2020-12-09 10:02:57 CET; 16h left gru 08 17:20:13 marek systemd[1]: Started Daily_borg_backup.
systemctl list-unit-files --type timer UNIT FILE STATE borgback.timer enabled
Jest aktywna i dalej nic. Zobacz, proszę, czy czegoś nie sknociłem w plikach service i timer:
cat /etc/systemd/system/borgback.service [Unit] Description=backup_borg ConditionACPower=true [Service] Type=oneshot ExecStart=sh /home/marek/.skrypty/mmcblk0/borgback.sh SyslogIdentifier=borg-home
Czy w linii powinno być ExecStart=/bin/bash czy sh (tak jak ręcznie odpalam z terminala)?
cat /etc/systemd/system/borgback.timer [Unit] Description=Daily_borg_backup [Timer] OnCalendar=*-*-* 10:00:00 RandomizedDelaySec=180 Persistent=true [Install] WantedBy=timers.target
Ostatnio edytowany przez mark (2020-12-08 18:10:41)
Offline
No nie dziw się skoro masz w ExecStart= to co masz. Powinno być coś w stylu:
ExecStart=/bin/sh -c "/moj/skrypt"
Te ścieżki do poleceń w usługach systemd zawsze muszą być absolutne.
Ostatnio edytowany przez morfik (2020-12-08 18:09:31)
Offline
I o to chodziło. Dzisiaj poszło gładko. Victoria!!!
morfik dziękuję za pomoc Tobie i pozostałym. Te Forum jest wspaniałe. Poobserwuję parę dni ale już teraz myślę że temat rozwiązany pomyślnie.
Offline
Jest jakiś konflikt. 5 usług wystartowało w tym samym momencie i dzisiaj borg nie wykonał swej roboty. Wczoraj po raz pierwszy od uruchomienia timera borg zadziałał, stąd moja przedwczesna euforia. Dzisiaj odmawia współpracy więc nie wiem czy powodem są pokrywające się czasy 5-ciu poniższych timerów. Ręcznie startuje bez problemu.
$ systemctl list-timers -l --no-pager --all NEXT LEFT LAST PASSED UNIT ACTIVATES Thu 2020-12-10 19:31:40 CET 42min left Thu 2020-12-10 18:33:34 CET 16min ago anacron.timer anacron.service Fri 2020-12-11 00:00:00 CET 5h 10min left Thu 2020-12-10 18:21:47 CET 27min ago logrotate.timer logrotate.service Fri 2020-12-11 00:00:00 CET 5h 10min left Thu 2020-12-10 18:21:47 CET 27min ago man-db.timer man-db.service Fri 2020-12-11 06:00:42 CET 11h left Thu 2020-12-10 18:21:47 CET 27min ago apt-daily-upgrade.timer apt-daily-upgrade.service Fri 2020-12-11 10:01:47 CET 15h left Thu 2020-12-10 18:21:47 CET 27min ago borgback.timer borgback.service Fri 2020-12-11 10:08:46 CET 15h left Thu 2020-12-10 18:21:47 CET 27min ago apt-daily.timer apt-daily.service Fri 2020-12-11 18:37:24 CET 23h left Thu 2020-12-10 18:37:24 CET 12min ago systemd-tmpfiles-clean.timer systemd-tmpfiles-clean.service 7 timers listed.
A czy powodem może być nie zamontowana karta pamięci w momencie uruchomienia systemu. Czas mam ustawiony w ten sposób:
[Unit] Description=Daily_borg_backup [Timer] OnCalendar=*-*-* 10:00:00 RandomizedDelaySec=180 Persistent=true [Install] WantedBy=timers.target
Nim uruchomię thunar i zamontuję kartę upływają sekundy, a co jeśli losowy czas uruchomienia timera będzie w 1-szej sekundzie lub następnej? Gdy w tym czasie karta jeszcze nie została zamontowana to proces się nie rozpocznie. Być może nie w tym rzecz ale sonduje dlaczego tak to chimerycznie działa.
Offline
Można w usłudze systemd dać warunek, że w systemie musi być określone urządzenie i tylko wtedy robić backup. Podobnie z punktem montowania czy ścieżką do katalogu by był np. do zapisu. Tutaj masz listę warunków jakie możesz podać w usłudze systemd.
Poza tym, daj status usługi i timer'a. Bo tam pisze czemu nie został uruchomiony.
Ostatnio edytowany przez morfik (2020-12-10 21:57:07)
Offline