🚀 go-pugleaf

Dnia Thu, 31 Mar 2011 12:01:31 +0000, laser napisał(a):

[...]
> Chodzi o jakiś prosty sposób czy ten program, uruchomiony jako TEN
> proces jeszcze żyje i żeby było to pewne. Tzn. że jak proces zdechnie to
> informacja o nim automatycznie znikała.
> 
> Czy można to jakoś zrealizować w prznośny sposób, bez korzystania z
> /proc ?

flock?

ethanak

Dnia 31.03.2011 ethanak <ethanak@autograf.pl> napisał/a:
> Dnia Thu, 31 Mar 2011 12:01:31 +0000, laser napisał(a):
>
> [...]
>> Chodzi o jakiś prosty sposób czy ten program, uruchomiony jako TEN
>> proces jeszcze żyje i żeby było to pewne. Tzn. że jak proces zdechnie to
>> informacja o nim automatycznie znikała.
>> 
> flock?

Dzięki za podpowiedz, wczytuję się.

-- 
ml

http://www.archimedes.eu.org/

On 03/31/2011 02:01 PM, laser@laser.lon wrote:
> Witam,
>
> Czyjest jakiś sprawdozny sposób na sprawdzenie czy uruchomiony program
> działa? Żeby nie było łatwo chodzi głównie o skrypty, które potem
> uruchamiają inne programy i same czekają aż się skończą.
>
> Teraz chodzi o stwierdzenie czy taki skrypt jeszcze działa (lub czeka na
> zakończnie swoich potomków).
>
> Wiem, że można, jak to się zwykle robi, zapisoać pid skryptu do pidfile i
> potem go odczytać. Problem w tym, że proces moze zejść w nieprzewidzian
> sposób, a plik z pid-em zostanie i potem trzeba jeszcze sprawdzać czy jest
> ocś o takim PID-e, a w miedzyczasie licznik na pid-y się przekręci i pojawi
> się zupełnie inny proces o tym nr (ale już nie nasz), itd.
>
> Chodzi o jakiś prosty sposób czy ten program, uruchomiony jako TEN proces
> jeszcze żyje i żeby było to pewne. Tzn. że jak proces zdechnie to informacja
> o nim automatycznie znikała.
>
> Czy można to jakoś zrealizować w prznośny sposób, bez korzystania z /proc ?

Jeżeli testujesz skrypt "s.sh", to najłatwiej prawdopodobnie:

#! /bin/sh
touch ROBI_SIE
sh s.sh
rm -f ROBI_SIE

A po co Ci to? Bo jeżeli np. chcesz spowodować, żeby druga kopia skryptu 
nie odpaliła się w czasie działania pierwszej, to proponuję tworzyć rurę 
przez "mkfifo <plik>" czy tam "mknod <plik> p" przy uruchomieniu skryptu 
a kasować przy zakończeniu - na wypadek niespodziewanych "exit" tu i tam 
w skrypcie kasowanie zrobić przez:

usunRure() { rm -f <plik> ; }
trap usunRure EXIT INT TERM QUIT

pod Linuksem w bashu wystarczy zdaje się tylko EXIT.

JD

Dnia 02.04.2011 Jêdrzej Dudkiewicz <jedrzej.dudkiewicz@nospam-gmail.com> napisa³/a:
> On 03/31/2011 02:01 PM, laser@laser.lon wrote:
>> Witam,
>>
>> Czyjest jaki¶ sprawdozny sposób na sprawdzenie czy uruchomiony program
>> dzia³a? ¯eby nie by³o ³atwo chodzi g³ównie o skrypty, które potem
>> uruchamiaj± inne programy i same czekaj± a¿ siê skoñcz±.
>>
>> Teraz chodzi o stwierdzenie czy taki skrypt jeszcze dzia³a (lub czeka na
>> zakoñcznie swoich potomków).
>>
>> Wiem, ¿e mo¿na, jak to siê zwykle robi, zapisoaæ pid skryptu do pidfile i
>> potem go odczytaæ. Problem w tym, ¿e proces moze zej¶æ w nieprzewidzian
>> sposób, a plik z pid-em zostanie i potem trzeba jeszcze sprawdzaæ czy jest
>> oc¶ o takim PID-e, a w miedzyczasie licznik na pid-y siê przekrêci i pojawi
>> siê zupe³nie inny proces o tym nr (ale ju¿ nie nasz), itd.
>>
>> Chodzi o jaki¶ prosty sposób czy ten program, uruchomiony jako TEN proces
>> jeszcze ¿yje i ¿eby by³o to pewne. Tzn. ¿e jak proces zdechnie to informacja
>> o nim automatycznie znika³a.
>>
>> Czy mo¿na to jako¶ zrealizowaæ w przno¶ny sposób, bez korzystania z /proc ?
>
> Je¿eli testujesz skrypt "s.sh", to naj³atwiej prawdopodobnie:
>
> #! /bin/sh
> touch ROBI_SIE
> sh s.sh
> rm -f ROBI_SIE
>
> A po co Ci to? Bo je¿eli np. chcesz spowodowaæ, ¿eby druga kopia skryptu 
> nie odpali³a siê w czasie dzia³ania pierwszej, to proponujê tworzyæ rurê 
> przez "mkfifo <plik>" czy tam "mknod <plik> p" przy uruchomieniu skryptu 
> a kasowaæ przy zakoñczeniu - na wypadek niespodziewanych "exit" tu i tam 
> w skrypcie kasowanie zrobiæ przez:
>
> usunRure() { rm -f <plik> ; }
> trap usunRure EXIT INT TERM QUIT
>
> pod Linuksem w bashu wystarczy zdaje siê tylko EXIT.
>
> JD

Hej,


Eee... chyba lepiej uzyc lockfile, do zablokowania wielokrotnego
wykonania (choc to w sumie tozsame z touch). Natomiast mozesz tez
sprawdzic czy sam skrypt dziala (i jego PID) taka konstrukcja:
for pid in $(pidof bash); do if [ $(cat /proc/$pid/cmdline) =
"/bin/bash./test.sh" ]; then echo $pid; fi; done

(zakladajac ze shell wykonujacy to bash). Moze da sie bardziej
elegancko, ale na szybko tylko to mi do glowy przychodzi


-- 
Pozdrawiam,
  Marcin Kwiatkowski

On 04/02/2011 10:31 PM, Marcin Kwiatkowski wrote:
> Dnia 02.04.2011 Jêdrzej Dudkiewicz<jedrzej.dudkiewicz@nospam-gmail.com>  napisa³/a:
>> On 03/31/2011 02:01 PM, laser@laser.lon wrote:
>>> Witam,
>>>
>>> Czyjest jaki¶ sprawdozny sposób na sprawdzenie czy uruchomiony program
>>> dzia³a? ¯eby nie by³o ³atwo chodzi g³ównie o skrypty, które potem
>>> uruchamiaj± inne programy i same czekaj± a¿ siê skoñcz±.
>>
>> Je¿eli testujesz skrypt "s.sh", to naj³atwiej prawdopodobnie:
>>
>> #! /bin/sh
>> touch ROBI_SIE
>> sh s.sh
>> rm -f ROBI_SIE
>>
>> A po co Ci to? Bo je¿eli np. chcesz spowodowaæ, ¿eby druga kopia skryptu
>> nie odpali³a siê w czasie dzia³ania pierwszej, to proponujê tworzyæ rurê
>> przez "mkfifo<plik>" czy tam "mknod<plik>  p" przy uruchomieniu skryptu
>> a kasowaæ przy zakoñczeniu - na wypadek niespodziewanych "exit" tu i tam
>> w skrypcie kasowanie zrobiæ przez:
>>
>> usunRure() { rm -f<plik>  ; }
>> trap usunRure EXIT INT TERM QUIT
>
> Eee... chyba lepiej uzyc lockfile, do zablokowania wielokrotnego
> wykonania

Możliwe, nigdy jeszcze nie użyłem lockfile w produkcji, bo niestety 
pracuję w środowisku, gdzie jego obecność jest niepewna.

> (choc to w sumie tozsame z touch).

A skąd.

> Natomiast mozesz tez
> sprawdzic czy sam skrypt dziala (i jego PID) taka konstrukcja:
> for pid in $(pidof bash); do if [ $(cat /proc/$pid/cmdline) =
> "/bin/bash./test.sh" ]; then echo $pid; fi; done
>
> (zakladajac ze shell wykonujacy to bash). Moze da sie bardziej
> elegancko, ale na szybko tylko to mi do glowy przychodzi

Pewnie można, ale należy zauważyć, że stawianie locka na tej podstawie 
jest obarczone "kondycją rasową", znaczy - mamy wyścig (wg wikipedii - 
"hazard").

JD