---

Jeg har samme problem i både slrn og newsbeuter. I begge programmer har
jeg sat min browser til Firefox eller rettere "firefox <url> &".

Hvis jeg starter 'firefox &' fra rxvt-vindue og afslutter (u)rxvt med
'exit'-kommandoen, så får Firefox lov at leve. Men hvis jeg afslutter
rxvt ved at klikke i krydset, så dør Firefox-processen også.

Hvis jeg afslutter slrn eller newsbeuter dør firefox-processen på
lignende facon (med mindre jeg selvfølgeligt bruger nohup¹). Det sker
selvom jeg afslutter både slrn og newsbeuter helt reglementeret.

Jeg havde forventet at en afslutning af slrn eller newsbeuter (med
Q-tasten) var ligeså "ren" som en 'exit'-kommando i rxvt, men
tilsyneladende kan jeg ligeså godt klikke i krydset på det vindue de er
åbne i - Firefox dør alligevel. Hvad sker der?

PS: I praksis har jeg '> /dev/null 2>&1' på også, men det gør ingen
forskel i denne sammenhæng, så jeg har udeladt det i beskrivelsen.

¹) Problemet er så bare, at teksten i newsbeuter-vinduet en gang imellem
bliver overskrevet med en besked om, at output er skrevet til
nohup.log, nohub.txt eller hvad den hedder. Derudover bliver denne
fil lavet i $PWD. Det gider jeg ikke.

---

Lars Stokholm wrote:
> Hvis jeg afslutter slrn eller newsbeuter dør firefox-processen på
> lignende facon (med mindre jeg selvfølgeligt bruger nohup¹). Det sker
> selvom jeg afslutter både slrn og newsbeuter helt reglementeret.

Måske skal jeg lige tilføje, at jeg starter begge programmer med
urxvt -e [program].

---

2009-05-09 Lars Stokholm wrote
> Jeg har samme problem i både slrn og newsbeuter. I begge programmer har
> jeg sat min browser til Firefox eller rettere "firefox <url> &".
>
> Hvis jeg starter 'firefox &' fra rxvt-vindue og afslutter (u)rxvt med
> 'exit'-kommandoen, så får Firefox lov at leve. Men hvis jeg afslutter
> rxvt ved at klikke i krydset, så dør Firefox-processen også.

Hvordan viser f.eks. pstree familie-forholdet imellem dine processer der?
Er din firrefox blevet barn af din bash?

Normalt kan et simpelt trick der være en dobbelt fork, men jeg har ikke lige
prøvet at lave det i bash.

Hvad hvis du i stedet for

firefox &

skriver

bash -c 'firefox &' &


/Morten

---

Morten Guldager wrote:
> Hvordan viser f.eks. pstree familie-forholdet imellem dine processer der?
> Er din firrefox blevet barn af din bash?

Nej, Firefox får sin egen gren under init.

> Normalt kan et simpelt trick der være en dobbelt fork, men jeg har ikke lige
> prøvet at lave det i bash.
>
> Hvad hvis du i stedet for
>
> firefox &
>
> skriver
>
> bash -c 'firefox &' &

Det blev til

browser "bash -c 'firefox %u &' &"

i newsbeuter, men det gør desværre ingen forskel.

---

Lars Stokholm skrev:

> Det blev til
>
> browser "bash -c 'firefox %u &' &"
>
> i newsbeuter, men det gør desværre ingen forskel.

Kan du mon bruge dette:

   browser "daemonize firefox '%u'"

hvor daemonize er den binære som er oversat fra:

#include <unistd.h>

int
main(int argc, char **argv)
{
int rc = daemon(1, 0);

if (rc)
return rc;

++argv;

return execvp(*argv, argv);
}


(oversæt med fx 'gcc -s -o daemonize{,.c}')

Mvh,

--
Klaus Alexander Seistrup
http://klaus.seistrup.dk/

---

Klaus Alexander Seistrup wrote:
> Kan du mon bruge dette:
>
>    browser "daemonize firefox '%u'"

Fantastisk. Det er ligesom et kinderæg. :) Mange tak.

Tilbage er bare spørgsmålet: Hvorfor er det nødvendigt?

---

Lars Stokholm wrote:
> Klaus Alexander Seistrup wrote:
>> Kan du mon bruge dette:
>>
>>    browser "daemonize firefox '%u'"
>
> Fantastisk. Det er ligesom et kinderæg. :) Mange tak.
>
> Tilbage er bare spørgsmålet: Hvorfor er det nødvendigt?
Når du lukker et terminalvindue ved at klikke på close (krydset) bliver
den shell, der kører i vinduet ikke termineret korrekt. En firefox
startet i baggrunden mister sit display, men bliver ikke lukket rigtigt
ned; firefox kører altså stadig, men er usynlig. Hvis man prøver at
starte en firefox igen får man en popup, der siger at der kører en
firefox, og man får valget mellem at restore firefox eller lukke firefox
endeligt.

--
Med venlig hilsen

Jørgen Heesche
mailto:heesche@webspeed.dk

---

Lars Stokholm skrev:

> Tilbage er bare spørgsmålet: Hvorfor er det nødvendigt?

Hvis man dræber en forældreproces, dræber man samtidig alle under-
liggende børneprocesser, tænker jeg (måske med mindre børnene har
fået deres egen session-id, som bl.a. er det daemon(3) sørger for).

Mvh,

--
Klaus Alexander Seistrup
http://klaus.seistrup.dk/

---

Klaus Alexander Seistrup wrote:
> Hvis man dræber en forældreproces, dræber man samtidig alle under-
> liggende børneprocesser, tænker jeg (måske med mindre børnene har
> fået deres egen session-id, som bl.a. er det daemon(3) sørger for).

Det giver også mening, men pstree viste jo netop, at Firefox ikke var et
barn til newsbeuter (f.eks.) men kun til init. Men du mener måske barn i
en anden forstand?

---

Jørgen Heesche wrote:
> Når du lukker et terminalvindue ved at klikke på close (krydset) bliver
> den shell, der kører i vinduet ikke termineret korrekt. En firefox
> startet i baggrunden mister sit display, men bliver ikke lukket rigtigt
> ned; firefox kører altså stadig, men er usynlig. Hvis man prøver at
> starte en firefox igen får man en popup, der siger at der kører en
> firefox, og man får valget mellem at restore firefox eller lukke firefox
> endeligt.

Firefox blev faktisk også lukket. Startede jeg en ny Firefox, blev jeg
spurgt om jeg ville genskabe sidste session eller starte en ny (i hvert
fald hvis jeg havde flere tabs åbne, svjks). Så den kører altså ikke
(heller ikke usynligt) - i hvert fald i min konfiguration.

---

Lars Stokholm <lars.stokholm@gmail.com> writes:

> Klaus Alexander Seistrup wrote:
>> Hvis man dræber en forældreproces, dræber man samtidig alle under-
>> liggende børneprocesser, tænker jeg (måske med mindre børnene har
>> fået deres egen session-id, som bl.a. er det daemon(3) sørger for).
>
> Det giver også mening, men pstree viste jo netop, at Firefox ikke var et
> barn til newsbeuter (f.eks.) men kun til init. Men du mener måske barn i
> en anden forstand?

Der er tale om to lidt forskellige forhold. Der er det simple
parent/child forhold, som pstree viser, og der er et koncept der
hedder process groups (session groups).

Parent/child-forholdet er primært af interesse når barnet dør. Så
bliver der sendt en SIGCHLD til parentprocessen og det er
parentprocessen der skal kalde wait(2) før barnet kan blive rydet
ordentligt op.

Process groups bliver primært brugt til at man kan sende et signal til
en hel process group på en gang. Hverken fork(2) eller execve(2)
skifter processgruppe, det skal gøres eksplicit med et kald til
setsid(2). Så hvis man bare forker et par gange, så forbliver man i
samme processgruppe og vil derfor modtage signaler til processgruppen.

//Makholm

---

On 2009-05-11, Peter Makholm <peter@makholm.net> wrote:

>> Det giver også mening, men pstree viste jo netop, at Firefox ikke var et
>> barn til newsbeuter (f.eks.) men kun til init. Men du mener måske barn i
>> en anden forstand?
>
> Der er tale om to lidt forskellige forhold. Der er det simple
> parent/child forhold, som pstree viser, og der er et koncept der
> hedder process groups (session groups).

Process groups og session groups er to forskellige ting, og der er
derfor to kald, der er interessante: setpgrp() og setsid().

--
Andreas

---

Andreas Plesner Jacobsen <apj@daarligstil.dk> writes:

> Process groups og session groups er to forskellige ting, og der er
> derfor to kald, der er interessante: setpgrp() og setsid().

Korrekt, men nært forbundne. setsid() har blandt andet den effekt at
den kaldende process kommer i sin egen process group og dette er et af
de væsentlige ønsker man har når man daemonisere en process.

//Makholm

---

On 2009-05-11, Peter Makholm <peter@makholm.net> wrote:
>
>> Process groups og session groups er to forskellige ting, og der er
>> derfor to kald, der er interessante: setpgrp() og setsid().
>
> Korrekt, men nært forbundne. setsid() har blandt andet den effekt at
> den kaldende process kommer i sin egen process group og dette er et af
> de væsentlige ønsker man har når man daemonisere en process.

Yep. Det var mest din parentes jeg havde et problem med.

--
Andreas

---

Peter Makholm wrote:
> Korrekt, men nært forbundne. setsid() har blandt andet den effekt at
> den kaldende process kommer i sin egen process group og dette er et af
> de væsentlige ønsker man har når man daemonisere en process.

Perfekt. Så 'setsid firefox > /dev/null 2>&1' gør vel nogenlunde det
samme som det daemonize-program Klaus havde lavet?

Det er i øvrigt underligt at 'setsid firefox <url>' ser ud til at "gå i
baggrunden", når jeg kalder det manuelt fra urxvt. Men hvis jeg putter
det i newsbeuters/slrns config-fil, så gør det ikke: Der er jeg nødt til
at putte det i baggrunden selv med &. Hvad skyldes det mon?