Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Ħαℓ₸℮ℵ ␏⫢ ⦚ 22. 03. 2024, 14:03:35
-
ve kterých případech v (ba)shi je a není volat příkaz disown ? Zadám příkaz-nebo-sérii-konstrukcí &. Následně zavřu shell a jdu třeba do kostela
(moje víra je systemd). Mám situace, kdy mi program skončí někdy i s disown a někdy disown není potřeba..
Co třeba konkrétně, když příkazy obalím do ()& ? (sleep 15 ; sleep 1200)& - druhý sleep běží i bez disownu
Je možné že zmatení pramení z překrývajícího problému, že programům se uzavře stdin /stdout, ale to bych chtěl vyvrátit nebo potvrdit, ale hlavně mě zajímá ten disown v první řadě.
Většinou jde o programy/sérii kde je sleep a nebo stahování, co trvá delší dobu
-
tak to záleží na tom, co děláš, že jo.
disown odstraní proces s jobů, takže ti zůstane běžet když uděláš exist, bash jim nepošle SIGHUP signál, ale pořád ty procesy mají bash jako parent, pořád jsou třeba pod tvým pty, takže se třeba s ukončením ssh spojení klidně zabijí (to je v pozici s nohup), ale to vše záleží na nastavení, pokud je nic nezabije, přesunout se nahoru, ztratí stdout/stderr, který měly z terminálu a není to pěkné.
Já to používám v situaci, kdy spouštím úlohy na pozadí, ale nechci odebírat jejich výsledek, sami si ho spravují a nechci, abych si ho omylem ukončil nebo na něj přes wait čekal. Není to ale častý use case.
-
Díky za objasnění, ale pořád tam mám tmavá místa. Jestli to dobře chápu, implicitně se neukončují aplikace pokud se ukončí parent? Ale většina posílá SIGHUP a většina na něj reaguje ukončením? nebo některé reaagují na SIG_PTY_Zavřeno_jak_se_Tento_signál_jmenuje?
Někdy mívám právě problém s ssh, to je dané tím pty?
třeba příkaz z bashe zsh -c "sleep 2e3" & killall zsh neukončí sleep a přestože nedávám disown... tomu nerozumím
co znamená "v pozici s nohup"...
není v příkazu nohup chyba(v dokumentaci, ne funkčnosti)? Sice to funguje jak má, ale pořád to píše přesměrovává na stdout
~ $ nohup ls >/dev/null
nohup: vstup ignoruji a stderr přesměrovávám na stdout
:~ $ nohup ls >/dev/stdout
nohup: vstup ignoruji a výstup připojuji k 'nohup.out'
:~ $ rm nohup.out
:~ $ nohup ls >/dev/zero
nohup: vstup ignoruji a stderr přesměrovávám na stdout
~ $
!!!
nohup sudo conntrack -L >/dev/null
nohup: vstup ignoruji a stderr přesměrovávám na stdout
.....přesměruje to i stderr do dev/null (vypisuje normálně spojení na stdout a "conntrack v1.4.5 (conntrack-tools): 23 flow entries have been shown." na stderr
Poznámka k poslednímu odstavci, disown, zároveň ale stále píšou do stdout. (while true ; do sleep 1 ; echo 1;done) &
111111; disown1111... Tím výsledek si myslel return code , nebo zmínku v shellu "[2] Finished" a ne "výsledek" jako výstup?
Nevím zda to s tím souvisí, ale zkoušel jsem echo $$; (sleep 1 ;echo $$ ; while true ; do sleep 1 ;echo 1;done) & -- obě PID jsou stejná. to znamená že bash nespouští jiný proces pro subshell? Některé shelly to tak mají a jiné ne? že forkují () ? Má to vliv na to pokračování v běhu při uzavření?
jeden příklad za všechny: (sleep 10 ; php phpmailer.php) & ---nedojde k odeslání., ale (sleep 10 ; php phpmailer.php >/dev/null) & j OK
-
Tak je divné, že tyhle příkazdy se chovají takhle různě:
wget https://www.klaus.cz/ -O- -S 2>&- ..nevypíše nic
wget https://www.klaus.cz/ -O- -S >&- vypíše hlavičky, ale ne tělo
naproti tomu
curl https://www.klaus.cz/ 2>&- vypíše tělo
curl https://www.klaus.cz/ 2>& vypíše header progreassu failed to writing
jako kdyby programy reagovaly různě na uzavřený výstup
Záleží třeba i na tom, v jakém pořadí zapisuje program nejdřív na jaký vstup?
sudo conntrack -L >&-
sudo conntrack -L 2>&-
vypíše tabulku spojení, i když stderr je uzavřen, vypíše v 1. případě počet spojení při při vypnutém stdtou (na stderr,vím)
ale oproti tomu ten php phpmailer >&- skončí chybou=neodešle mail
Je to něčím konkrétním a nebo prostě specifickou implemantací programů? že php vyžaduje stdout a když ne, skončí, ale třeba conntrack když detekuje ,že nemá stderr/stdout,, tak si jede dál?
-
no, když to víš dopředu, tak není potřeba disown, ale dáš nohup
nohup dlouhy_skript.sh > out&