Leuke vraag!

"Normaal" gesproken zou het denk ik gewoon moeten werken. Als je een parent killed worden de children "oprhaned" en zouden ze automatisch "adopted" moeten worden door init. Of in andere woorden, als je een child killed wordt het "init" proces automatisch zijn nieuwe parent.

Als dat niet gebeurd (en daar ga ik vanuit gezien je posting) is er vast wat anders aan de hand. Misschien gaat het child proces om een andere reden dood? Theorietsch zou je kunnen kijken of het process en controlling terminal nodig heeft (lijk me sterk), maar maybe eens spelen met "disown" ? (bash commandline).

En zoals altijd, stackoverflow heeft goede tips!

Mischien helpt dit je iets verder: https://en.wikipedia.org/wiki/Nohup

Je kan niet de parent vermoorden en dan kinderen hun taak continue laten uitvoeren want de kinderen willen een signal sturen naar de parent, tenzij je het zo hebt ingericht dat de parent de kinderen moet vermoorden als de ouder niks waar neemt.

Ik start in een shell het volgende:

mc en dan typ ik sleep 10m (kon even niets anders verzinnen)

dan heb ik in een andere shell de volgende pstree output:

|-gnome-terminal--+-bash---mc---bash---sleep

ps aux zegt:

root 16776 0.0 0.0 3888 752 pts/2 S+ 01:47 0:00 sleep 10m

als ik dan typ:

disown 16776

krijg ik:

bash: disown: 16776: no such job

Verwarrend. Werkt dit commando alleen met ctrl-z als het child process draait?

Zoals omschreven op https://www.serverwatch.com/tutorials/article.php/3935306/Detach-Processes-With-Disown-and-Nohup.htm

Dit is dus niet wat ik zoek en werkt niet. Is er een manier om een child process uit de processtree te tillen naar een eigen pid onder init zonder gedoe?

Het lijkt alleen maar te kunnen als een child process in de voorgrond zit en dan moet je eerst suspend doen (ctrl-z), en backgrounden (bg) en vervolgens disown. Een hoop gedoe dus.

Dit moet toch ook kunnen als het niet op de voorgrond draait, met / in een nieuwe terminal net zoals de commando's nice / renice.

Volgens mij zit ik te prutsen.

ik moest bij deze thread denken aan deze cartoon over het verschil tussen SIGTERM en SIGKILL
http://turnoff.us/geek/dont-sigkill/

Ngggaaaaaarg! ;-)


Leuq en cute maar dat beantwoord de vraag nog niet. Als er geen sprake is van threading en depencencies is een child process gewoon autonoom in een pstree. Is er een commando om zo'n proc te isoleren, dus dat een child process in plaats van een subsidiary process wordt losgemaakt en direct onder init (1) komt met een andere tool dan het hele gedoe met "foreground,ctrl-z,bg,disown" want dat zijn nogal wat vage handelingen voor iets wat in theorie ook moet kunnen met een enkel commando als UID=0.

Dus als een child proc op de achtergrond (niet in een visible control terminal) draait, bijvoorbeeld door het backgrounden van een process en het sluiten van de terminal, is het child proces niet meer te bereiken zonder de hele family structuur te killen? Zeg me niet dat ik een functionaliteitsgebrek heb ontdekt in het POSIX systeem ;)

De oorspronkelijke bedoeling van SIGHUP is om een proces te vertellen dat de seriële lijn waar de fysieke terminal aan hangt verbroken is (HUP = hangup). De standaardreactie van zo'n process is dan om zich af te sluiten, al kan in het proces zelf geprogrammeerd zijn dat het anders reageert. Tegenwoordig wordt het veelal gebruikt om aan te geven dat een terminalvenster is afgesloten.

Als je vooraf weet dat je wilt dat het proces niet op SIGHUP moet reageren kan je het starten met:

Disown is een ingebouwd bash-commando, en het heeft alleen betrekking op achtergrondjobs van een bash-sessie. Je kan dus geen jobs in een andere bash-sessie daarmee loskoppelen.

Met CTRL+Z zet je een job stil en kan je nieuwe commando's intypen. Als je wilt dat de job doordraait dan kan je het met het bg-commando weer door laten lopen, maar dan op de achtergrond (bg=background). Bijvoorbeeld:
Zoals je ziet gebruik je niet het PID van het proces maar refereer je aan de job met %1, %2 etc. Het nummer is wat tussen de blokhaken staat in de uitvoer hierboven. Als je het weglaat heeft de shell een opvatting over wat de 'current job' is.

Als een job eenmaal op de achtergrond loopt kan je het met disown loskoppelen van de bash-sessie:
Daarna zal het geen SIGHUP meer ontvangen als je de shell afsluit.

Poeh, ik denk niet dat dat gaat en ook niet dat het een goed idee is. Als een browser meerdere tabs als child-processen start dan heb je een goede kans dat de parent en die children met elkaar communiceren en van elkaar verwachten dat ze er zijn. Mocht je er al in slagen om een parent weg te krijgen en een child door te laten lopen dan grijp je in in een stelsel van processen op een manier waar de makers van de software niet op geanticipeerd zullen hebben. Ik zou er niet op rekenen dat die java applet stabiel door blijft lopen, daar kan van alles misgaan.

Ik weet dat SIGHUP stamt uit de tijd van modem maar nohup vooraf starten en laten runnen wist ik niet. Het commando herinner ik me wel dus dit ga ik eens proberen. Beter vooraf duidelijk zijn naar het systeem toe het is namelijk een openbaar multi-user systeem met meerdere admins. Zo heb ik meer controle.


Thank u