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/.
Z bashem nie miałem w życiu wiele do czynienia, dlatego mam prośbę aby ktoś doświadczony sprawdził poniższy skrypt
#!/bin/bash
mt -f /dev/nst0 eod
/etc/init.d/jboss stop
while [ 1 ]; do
{
if [ -z "$(pgrep jboss)" ]; then
{
tar -cf /dev/nst0 /srv/jboss_std/ "..." &
}
fi
sleep 60
}
done
while [ 1 ]; do
{
if [ -z "$(pgrep tar)" ]; then
{
/etc/init.d/jboss start "..." &
}
fi
sleep 300
}
doneOstatnio edytowany przez general (2011-02-11 14:50:38)
Offline

Członek DUG


żeby sprawdzić musisz napisać co to ma robić.
Offline




Użyszkodnik
To co pisze tomii to raz, a dwa: pierwsza pętla jest nieskończona, więc druga nigdy się nie wykona. To chyba nie tak ma być?
Offline
Sprawdzałem skrypt poleceniem bash -n skrypt.sh . W drugiej pętli trochę pokasowałem i wtedy pojawiały się błędy. Jednak czy mogę mieć pewność, że całość się wykona.
Tomii. Skrypt ma wykonać pełną kopię katalogu /srv/jboss na taśmę. Najpierw jednak musi zatrzymać proces jboos, który chula po plikach. Na sam koniec, czyli po skończonym zapisie, ma jbossa reaktywować.
Pierwsza pętla sprawdza czy jboos "zdechł" Jeżeli tak to do akcji wkracza tar. Jeżeli nie to do czeka 1 minutę.
Druga pętla sprawdza tara i uruchamia jbossa.
Ostatnio edytowany przez general (2011-02-09 14:17:58)
Offline

Członek DUG


Nadal nie napisałeś co ma robić ten skrypt. Nie napisałeś jakie błędy się pojawiły. Co się ma wykonać?
Offline
Te błędy nie są istotne. Ciachnąłem po prostu kawałek kodu w drugie pętli tylko po to, żeby sprawdzi czy bash -n rzuci coś w ekran.
Offline




Użyszkodnik
general napisał(-a):
Tomii. Skrypt ma wykonać pełną kopię katalogu /srv/jboss na taśmę. Najpierw jednak musi zatrzymać proces jboos, który chula po plikach. Na sam koniec, czyli po skończonym zapisie, ma jbossa reaktywować.
No to sprawa jest prosta:
1. zatrzymujesz proces jboss
1.a. opcjonalnie — upewniasz się że jboss nie działa (wysyłasz mu kill tak długo, jak istnieje jakiś jego proces — tutaj jest miejsce na pętle). Jeśli jednak zatrzymanie daemona nie zawsze kończy działanie jboss, to znaczy że jboss jest poważnie spierdzielony i musisz mieć naprawdę solidne powody żeby go nadal używać.
2. Uruchamiasz tara.
3. Gdy tar zakończy pracę (możesz jeszcze sprawdzać status wyjścia -> sprawdź ten wątek), ponownie uruchamiasz jboss
W całym skrypcie jest miejsce na najwyżej jedną pętlę. Poza tym po prostu wklejasz normalne polecenia które i tak byś wykonał chcąc osiągnąć założony cel.
Offline
Zamiast pętli funkcje (?)
#!/bin/bash
mt -f /dev/nst0 eod
/etc/init.d/jboss stop
kopia (){
if [ -z "$(pgrep jboss)" ];
then
tar -cf /dev/nst0 /srv/jboss_std/
exit
fi
sleep 60
return
}
jboss(){
if [ -z "$(pgrep tar)" ];
then
/etc/init.d/jboss start
exit
fi
sleep 300
return
}Ostatnio edytowany przez general (2011-02-11 14:50:50)
Offline




Użyszkodnik
Oh come on...
#!/bin/bash
mt -f /dev/nst0 eod
/etc/init.d/jboss stop
while pgrep jboss >/dev/null 2>&1; do
pkill jboss
sleep 10
done
tar -cf /dev/nst0 /srv/jboss_std/
/etc/init.d/jboss startNie wiem w czym (i czy w ogóle) dotychczas programowałeś, ale albo niesamowicie utrudniasz proste zadania, albo to zadanie wcale nie jest takie banalne jakie się wydaje.
Nawiasem mówiąc, wrzucanie starowanej kopii na nośnik (taki jak taśma) nie jest najlepszym pomysłem. Jeśli uszkodzeniu ulegnie jakiś fragment taśmy, całe archiwum pójdzie się walić. No ale wychodzę z założenia że już to przemyślałeś i jesteś gotowy na taką niedogodność.
Offline
Minio. Może tak.
/etc/init.d/jboss stop
tar -cf /dev/nst0 /srv/jboss_std/
Nie ma problemu z zamykaniem jboss-a, ale takie pytanie: czy tar wykona się dopiero wtedy kiedy ten proces się zamknie?
Napęd i taśmy LTO3. Jedno z wielu zabezpieczeń.
http://www.radio3net.ro/dbalbums/albume1001/page:1 (zajrzyj tutaj)
Ostatnio edytowany przez general (2011-02-10 22:20:18)
Offline




Użyszkodnik
general napisał(-a):
Nie ma problemu z zamykaniem jboss-a, ale takie pytanie: czy tar wykona się dopiero kiedy ten proces się zamknie?
Generalnie tak. Następne polecenie wykona się dopiero gdy zakończy się poprzednie. Z tym, że skrypt zamykający pracę jbossa może być tak napisany, że pozwala na wykonywanie następnych poleceń zanim rzeczywiście zakończy swoją pracę. Trudno powiedzieć, bo ja tego skryptu na oczy nie widziałem.
Na wszelki wypadek, jeśli możesz, to po komendzie jboss stop daj jeszcze sleep na kilka(naście) sekund. Nie powinno to być potrzebne, ale jeśli masz obawy, to nie zaszkodzi.
general napisał(-a):
http://www.radio3net.ro/dbalbums/albume1001/page:1 (zajrzyj tutaj)
Umm... po co? Bo niezbyt rozumiem co ta strona ma wspólnego z problemem. Nie pomyliłeś czasem linków? ;)
Offline
"Muzyka ma dla mnie wyjątkowe znaczenie".
Ostatnio edytowany przez general (2011-02-10 22:27:33)
Offline




Użyszkodnik
general napisał(-a):
"Muzyka ma dla mnie wyjątkowe znaczenie".
Muszę w końcu nową stronę napisać ;) .
Offline




Moderator Mamut
Minio napisał(-a):
Nawiasem mówiąc, wrzucanie starowanej kopii na nośnik (taki jak taśma) nie jest najlepszym pomysłem. Jeśli uszkodzeniu ulegnie jakiś fragment taśmy, całe archiwum pójdzie się walić. No ale wychodzę z założenia że już to przemyślałeś i jesteś gotowy na taką niedogodność.
nie w przypadku tar'a ... ten format byl tworzony z mysla o tasmach ... tam ogolnie jest zapisywany naglowek (informacje o pliku) oraz tresc pliku a potem kolejny itd ... uszkodzenie fragmentu spowoduje problem tylko w pliku na ktory trafilo ...
Offline




Użyszkodnik
bercik: a może. Przede wszystkim nie zwróciłem uwagi, że tam jest sam tar, bez dodatkowej kompresji. Przyzwyczaiłem się że jak leci tar, to od razu z gzipem czy bzipem.
W takim razie wychodzi że palnąłem głupotę.
Offline
#!/bin/bash
mt -f /dev/nst0 eod
/etc/init.d/jboss stop
/etc/init.d/pz stop
sleep 60
tar -cf /dev/nst0 /srv/jboss_std
/etc/init.d/jboss start
/etc/init.d/pz start
Ostatnio edytowany przez general (2011-02-22 10:00:28)
Offline