Dotaz: Jak v shellu poslat "signál" jinému uživateli?

[Jiří Lisický]

Jak co nejlíp předat v shellu nějaký signál nebo zkrátka nějakou krátkou informaci - takový spuštěč jinému uživateli?

O co jde. Píšu v shellu nějaké zpracování dat. Chci mít oddělený příjem od zpracování, takže mám dva uživatele. Jeden přijme data z jiného serveru přes ssh a měl by nějak dát vědět druhému uživateli, aby ty data zpracoval.

I to "dát vědět" bych mohl udělat přes ssh, ale připadne mi to zbytečně overkill. Možná to zkusím udělat nějak přes sudo. Ale třeba máte někdo nějaký lepší nápad.

Odpovědi

[azurIt]

co tak vytvorit nejaky (prazdny) subor ? druhy user bude v cykle checkovat, ci subor existuje. ak ano, spracuje data a zmaze ho.

[Michal Kubeček]

Nebylo by jednodušší rovnou použít pojmenovanou rouru?

[Hynek (Pichi) Vychodil]

Ano, osobně bych se přikláněl také k pojmenované rouře někde ve var, do které bude smět zapisovat pouze user1 a proces pod user2 z něj bude chtít číst.

[Josef Kufner]

někde ve var,

/var/run, /tmp nebo /var/tmp. Jinde to nemá co dělat.

[Hynek (Pichi) Vychodil]

Vážně? A co takhle /var/spool/<jméno služby> když to budu považovat za systémovou službu, tak je to naprosto adekvátní místo.

[Josef Kufner]

No dobře, no.

[Martin Lebeda]

Já osobně to mám takto:

mkfifo /tmp/alarm
chmod 660 /tmp/alarm

A pod svou session startuji: while true; do osd_cat ... < /tmp/alarm; done &

Jakýkoliv program pak může provést echo "zprava" > /tmp/alarm.

[Jiří Lisický]

Nějakému cyklu či cronu jsem se právě chtěl vyhnout...

[Hynek (Pichi) Vychodil]

A to jako ten signál chcete poslat neexistujícímu (neběžícímu) procesu? Nebo v čem jiném by ten váš druhý program byl než ve smyčce. Asi vám vůbec není jasné jak to funguje, protože ten script čeká na vstup a tedy nijak nevytěžuje cpu.

[trekker.dk]

Nebo v čem jiném by ten váš druhý program byl než ve smyčce.

Může být ve stavu čekání na signál. Kdyby běžel ve smyčce, bude zbytečně vytěžovat CPU.

[Michal Kubeček]

Jenže on právě v žádné smyčce běžet nebude, bude ve stavu S a čekat na vstup z té roury.

[trekker.dk]

Nebo v čem jiném by ten váš druhý program byl než ve smyčce.

Může být ve stavu čekání na signál. Kdyby běžel ve smyčce, bude zbytečně vytěžovat CPU.

Jenže on právě v žádné smyčce běžet nebude, bude ve stavu S a čekat na vstup z té roury.

Přiznávám se bez mučení, že mám asi dlouhé vedení, ale ten tvůj příspěvek nechápu...

[azurIt]

ale to cakanie na signal bude v cykle..

[Martin Lebeda]

Pokud čte z roury tak v žádné smyčce není. Zkuste si to spustit jen tak v terminálu. Zjistíte, že se spustí a zastaví se na čtení a nepokračuje, dokud nemá načtena data, tj. dokud do roury jiný proces nepustí EOF. Když má načteno tak pokračuje, tj. zobrazí načtený text a ukončí se.

Smyčka jej znovu spustí a on se opět zastaví dokud nepřijde vstup. Je zcela lhostejné, zda čeká na vstup sekundu nebo 2 hodiny, po tu dobu se neprovádí žádné instrukce a program stojí.

[azurIt]

samozrejme, ale cele to je stale v cykle. tomu sa proste neda vyhnut.

[Aleš Kapica]

Jasně, ale stručně řečeno - ta smyčka žádný čas procesu nežere. Je použitá jen na to, aby se nahodil znovu osd_cat. Ten se totiž jinak po obdržení EOF ukončí.

[azurIt]

jasne, ja to cele chapem! :) len reagujem na toto:
"Nějakému cyklu či cronu jsem se právě chtěl vyhnout..."

vsetky prispevky pod tym vyznievaju ako 'skvele riesenie bez cyklov' co nie je vobec pravda.

[Aleš Kapica]

Dotyčný totiž nejspíš chtěl vyhnout řešení, které by opakovaně kontrolovalo nějaký soubor, jestli do něj něco náhodou nepřibylo. Ovšem toto řešení zrovna takto nefunguje, protože pokud si třeba do té roury nechá posílat obsah jiné roury, tak žádný EOF nepřijde a osd_cat prostě vypisuje obsah roury na obrazovku. Jinými slovy ta smyčka není nezbytně nutná, zbaví vás jen nutnosti znovu nahazovat osd_cat v případě že na něj ten EOF náhodou někdo pošle..

[Jiří Lisický]

Dotyčný se taky dost blbě vyjádřil. Ale nakonec to udělal přes to sudo. Což vypadá, že by mu mohlo vyhovovat.

Akorát zjistil, že v tom scriptu spuštěném přes sudo nemá práva na zápis do /dev/stderr

[Jiří (BoodOk) Kadeřávek]

Taky jsem tu diskusi úplně nepochopil. Zřejmě byla o tom, na jaké úrovni ta smyčka běží, přičemž někteří zastavají názor, že od jisté dostatečně nízké úrovně už se o žádné smyčce hovořit nedá. Tohle dokáží jen lidé

[Jiří (BoodOk) Kadeřávek]

Taky jsem tu diskusi úplně nepochopil. Zřejmě byla o tom, na jaké úrovni ta smyčka běží, přičemž někteří zastavají názor, že od jisté dostatečně nízké úrovně už se o žádné smyčce hovořit nedá. Tohle dokáží jen lidé

[Josef Kufner]

Říká se tomu aktivní a pasivní čekání.

Při aktivním čekání běží program ve smyčce a periodicky kontroluje, zda už nastalo to, nač čeká.

while true
do
   # čekání
   while ! [ -f /tmp/baf ]
   do
      sleep 1
   done
   rm -f /tmp/baf
 
   # reakce 
   echo Lek.
done

… je ukázkou aktivního čekání na událost:

touch /tmp/baf

Kdežto při pasivním čekání program prostě řekne operačnímu systému "Hele až se něco bude dít, tak mě vzbuď." a jde spát.

mkfifo /tmp/fifo
while true
do
   # čekání
   cat /tmp/fifo >/dev/null
 
   # reakce
   echo Lek.
done

Bude čekat na událost:

echo Baf >/tmp/fifo

Jak je vidět, oba programy mají nějakou hlavní smyčku, která však s vlastním čekáním nemá vůbec nic společného a v žádném z případů by tam nemusela být – program by pak počkal na jednu událost a skončil.

Nicméně v případě aktivního čekání by bylo možné nahradit čekací cyklus jednoduchou konstrukcí if a nechat program běhat ve hlavní smyčce. To je vhodné, pokud by program měl provádět více věcí najednou. Pro pasivní čekání by bylo v takovém případě nutno využít něco jako select() či alarm(), což má své výhody i nevýhody.

Tak snad už je jasné, kde který cyklus je a co dělá nebo spíš nedělá

[azurIt]

a komu to jasne nebolo ?

[podlesh]

Nestačilo by klasické write ?

Nebo talk, v komibnaci s pípáním to nelze ignorovat

[cynik]

Delal bych to uplne stejne jako v C cili posilanim signalu. Pres trap se nadefinuje ovladac signalu:

trap 'echo dostal jsem' USR1

a pres kill se mu z jineho procesu posle signal:

kill -USR1 [cislo processu]

[Michal Kubeček]

Má to drobnou chybu: nejste-li root, nemůžete posílat signály cizím procesům. Proto asi tazatel zdůrazňoval, že ty dva procesy běží pod různými uživateli.

[houska]

shutdown -k now "zprava"

[Hynek (Pichi) Vychodil]

Hmm, taky dobré, jen co kdyby jste si přečetl i něco víc než jen nadpis.

[Hynek (Pichi) Vychodil]

A co takhle sudo a rovnou to zpracování spustit z toho prvního scriptu, třeba i na pozadí.

[mikky]

Já bych to asi řešil přes tu pojmenovanou rouru a cyklus:

mkfifo /tmp/mojeroura

a pak zpracovávací skript

while read promenna < /tmp/mojeroura; do
    if [ $promenna == zpracuj ] then
        #proved zpracovani
    fi 
    #pripadne misto if nejaky case pro vic moznosti
done

Upřímě nechápu, proč se chceš vyhnout cyklům? Jasně, třeba cykly typu "while /bin/true; do if grep "akce" /tmp/ridicisoubor; then udelej_akci; fi; sleep 1; done" jsou trošku hloupý, ale když se cyklus postaví tak, jak jsem psal, při volání příkazu read se skript zastaví a bude čekat tak dlouho, dokud se v rouře neobjeví informace. Pokud informace bude EOF, cyklus se ukončí. Pokud bude něco jiného, řádek se uloží do proměnné "promenna" a dá se s ní pak v tělě cyklu pracovat...

-miky

PS. řešit to přes sudo? neni to drobet brutální?

[Hynek (Pichi) Vychodil]

PS. řešit to přes sudo? neni to drobet brutální?

No ve srovnání s psaním nějakého scriptu, který musí jako proces běžet celou dobu a mít vyřešen případný respawn, protože spadnout to může vždycky atd, ... No tak sudo je teda fakt jednodužší a mnohem spolehlivější způsob.

[Josef Kufner]

Respawn se řeší zrovna celkem lehce – viz /etc/inittab. Ale vzhledem k tomu, že tazatel neprozradil o co vlastně jde, lze jen těžko rozhodnout, které řešení je nejvhodnější v tomto případě.