1

Onderwerp: sockets open gehouden door dochter process ?

Ik had vandaag de volgende situatie op een HP-UX systeem.

een process (A) opent een socket en luisterd daar op voor inkomende requests.
Zodra een aanvraag op die socket binnen komt word deze request via een eenvoudig protocolletje gelezen
Het process forkt dan en roept vervolgens mbv het system commando programma B aan.
Zodra B klaar is, wordt ook de fork van A gestopt.

Welnu ergens hing de boel ik kon A niet meer opstarten (reusesocket=0 dus vergeet het dan maar)
Alle instances van A gekilled maar nog steeds nogo

met netwerk tools (netstat ddn) de openstaande verbindingen gesloten maar nada..
de listener bleef actief ondanks dat alle instances van Process A gekilled waren.

Uiteindelijk kwam ik er achter dat en nog een process B liep.
Toen ik dat gekilled had, waren de problemen over.

Nu is het mij uiteraard duidelijk dat de files (en dus de sockets) van process A open blijven totdat B klaar is
en A de files (en dus de sockets) netjes afsluit.

Wat ik echter niet begreep is waarom deze kenlijk niet gesloten waren terwijl A feitelijk niet meer bestond
De filehandles werden pas gesloten tot een hangend B process ook gesloten werd.
Achteraf  begrijp ik dus wel waarom de boel niet meer werkte, maar niet waarom van een gekilled process de files toch open bleven.

Is dit ergens in de UNIX standaard gedefinieerd ?

Pascal's Blobfree Homepage
Een dag geen NedLinux is een dag niet geleefd

2

Re: sockets open gehouden door dochter process ?

Hoi Pascal,

Zoals jij het uitlegt, zal dit voor een buitenstaander "abracadabra" zijn. Maar dit heeft met programmeren te maken.
Ik begrijp je echter wel:
De originele A (server) zou eigenlijk altijd actief moeten zijn en blijven.
Er kan geen B zonder een "geforkte/gecopiëerde" A bestaan.

Kennelijk heb je de originele A in je "woede (grapje ;-)"  ook afgesloten, waardoor er een "wees" ontstond.
Een "zielig" over gebleven B op zoek naar een A. Iets anders kan ik mij niet voorstellen,

Of:
Er gaat nu bij mij ECHT een lamp branden!!!
Er is een B die de originele A afsluit.
De daarna volgende B roept/schreeuwt naar A maar krijgt geen antwoord meer terug: A=dood!!!
B= een wees. Dan komen er ook nog eens de wezen B1, B2, B3 etc. bij. ;-)
Je bent dan keihard opweg naar een "dead-end", ofwel een computer die nergens meer op reageert...

Zonder flauwekul:
Je hebt toch geen B als "afsluiter" geprogrammeerd? Een  B die de originele A moet afsluiten?
Niet If...then, daar zit dan ook de crux, de fout.

Je moet een C: programmeren, een mooie dame die alles voor je afsluit: ook de originele A!!!

Dit is supergemeen / laag van mij:
Mensen die echt van programmeren houden, herkennen 3 programmeer-talen in deze laatste zinsnede...

Pascal,
Ik hoef hier absoluut geen gelijk in te krijgen, Ik ga met je mee...
Ergens denken we fout.
Mee-denken is belangrijker dan gelijk krijgen.

Groetjes, Marcel

3 Laatst bewerkt door pascal (16 Jun 2015 19:23:54)

Re: sockets open gehouden door dochter process ?

Masy schreef:

Hoi Pascal,

Zoals jij het uitlegt, zal dit voor een buitenstaander "abracadabra" zijn. Maar dit heeft met programmeren te maken.

Waarom ? Er waren tijden dat dit forum gedomineerd werd door echte unix cracks.
Die reageren niet meer maar ze zijn er wel nog.

Masy schreef:

Ik begrijp je echter wel:

Mooi !

Marcel,
Programma B is een seperaat programma geen fork !
Programma A forkt, en die fork start B op.
Ik zie geen reden waarom B niet zou kunnen bestaan zonder A,
Feit is dat het gebeurde... (overigens is HP-UX bepaald niet het zelfde als Linux)
B stopt normaliter als elk ander programma met een return n, maar ditmaal hing het ding (nog in Beta stadium)
Waneer B stop vervalt de controlle normaliter weer bij de fork van A die de socket netjes afsluit en het process laat sterven.
punt was dat B er simply niet meer was ps -ef | grep programma_A
Nu ja. ik heb er een notitie van gemaakt, als ik weer eens een issue heb kom ik dat wel weer tegen.

Pascal's Blobfree Homepage
Een dag geen NedLinux is een dag niet geleefd

4

Re: sockets open gehouden door dochter process ?

Best interessante case.
Begrijp ik het goed dat de request die A op de socket ontvangt, door B wordt afgehandeld?

Help mee om KDE 5 in het Nederlands te vertalen!!

5 Laatst bewerkt door pascal (16 Jun 2015 21:17:35)

Re: sockets open gehouden door dochter process ?

Klopt Rinse dat is het idee.
A dient enkel voor het accepteren van de netwerk requests en B doet er wat mee.
Situatie is vergelijkbaar met een webserver die een cgi script uitvoert.
Vergelijkbaar maar een webserver forkt niet, die heeft meerdere threads

Pascal's Blobfree Homepage
Een dag geen NedLinux is een dag niet geleefd

6

Re: sockets open gehouden door dochter process ?

Maar is dat dan niet de reden waarom de socket open blijft? Doordat B via die socket de request afhandelt?

Help mee om KDE 5 in het Nederlands te vertalen!!

7

Re: sockets open gehouden door dochter process ?

jaja dat is ook de bedoeling. hier een voorbeeld in pseudo code

fork_A:
{
    read_data_from_connection
    call programma_B
    close_connection
}

Maar B is een standalone programma  en heeft A beslist niet nodig.
als B nog draait en ik kill fork_A    wat gebeurd er dan met de resources van fork_A ???

Pascal's Blobfree Homepage
Een dag geen NedLinux is een dag niet geleefd

8

Re: sockets open gehouden door dochter process ?

Je bevestigd het weer:-)
A forkt en start B op. Dus zonder A geen B...
Maw. als er een fork/copy van A is, is er ook een B actief.

Wat als er een B actief is voordat A opstart?
Heb je dat al eens getest?

9

Re: sockets open gehouden door dochter process ?

Volgens mij vat je hem niet,  de vraag is waarom de socket open blijft als B actief is, terwijl A niet draait.

Help mee om KDE 5 in het Nederlands te vertalen!!

10

Re: sockets open gehouden door dochter process ?

Hoi Pascal,

Zoals gezegd, denk ik met je mee. Ik heb "gegoogled" op HP-UX. (Nog nooit van gehoord)
Ik begrijp dat je waarschijnlijk met UNIX programmering bezig bent.
Dit is best heftig en "realy cool/vet"...

Ik programmeer zelf met pascal (Héé, jouw naam) onder Linux en Windows (http://www.lazarus-ide.org/) en Gamba's Basic onder Linux (http://gambas.sourceforge.net/en/main.html) en maak af en toe zelf scriptjes voor de terminal/console...

Wat ik weet/ervaren heb met in een eigen programma een extern (niet zelf geschreven programma) op te starten middels een call/exec/start/run
is dat als er geen data overdracht is, dit geen enkel probleem is. Een simpele call en verder geen controle...

Anders wordt het als je wil controleren of zo'n programma/proces (PID):
- maar 1 keer opgestart mag worden (RunOnce), géén kinderen/childs toegestaan;
- of dat het extern programma daadwerkelijk gestart is;
- er data-overdracht moet plaatsvinden. Een functie/function(argumenten). Binnen Windows zijn dit vaak DLL's die je aanroept;

Gelet op de problemen die jij ondervind, zul je waarschijnlijk controle mechanismen moeten inbouwen:
(Nogmaals: ik denk met je mee en ik heb absoluut geen gelijk!!!)

pid = fork()
if(pid){
  // I am parent. Let us do something that only the parent has to do
}else{
// I am child. Let us do something only the child has to do
}
// This code is common to both

Volgens mij zou een RunOnce bij jou er zo uit kunnen zien:
if (fork() == 0)
exit(0); /* first parent */

Verder adviseren sommige Unix-programmeurs de forks() onafhankelijk van het "ouder/parent"-proces te laten draaien.
Als het kind/child process onverwacht "afstort", blijft de parent altijd intact:

De code hiervan ziet er dan zo uit:

if (fork() != 0)
exit(0); /* first parent */
/* first child */
setpgrp(); /* lose controlling terminal & change process group */
signal(SIGHUP, SIG_IGN); /* immune from pgrp leader death */
if (fork() != 0) /* become non-pgrp-leader */
exit(0); /* first child */
/* second child */


Programmeren is echt leuk. Helaas is er de wet van Murphy (https://nl.wikipedia.org/wiki/Wet_van_Murphy)...
Ik hoop echt dat je hieraan wat hebt. Veel zul je absoluut beter weten als ik.
Maar ik wil met je meedenken, meewerken aan een oplossing van je probleem.

Bovenstaande wijsheden heb ik gehaald uit:
http://stackoverflow.com/questions/1243 … -statement
http://cjh.polyplex.org/software/daemon.pdf
http://mij.oltrelinux.com/devel/unixprg/#tasks_examples
http://mij.oltrelinux.com/devel/unixprg/

Scheelt je weer zoeken op internet.

Sucses Masy.

11

Re: sockets open gehouden door dochter process ?

Je zou bijna denken dat Masy het heeft tegen een brugpieper, dan tegen Capt. Pascal.

ACAB: All computers are broken. https://medium.com/message/everything-i … e5f33a24e1 "I've decided that you need gray hair and hemorrhoids to be a consultant.
The gray hair makes you look distinguished & the hemorrhoids make you look concerned."

12

Re: sockets open gehouden door dochter process ?

Niet dus!!!
Het gaat om ervarings-uitwisseling. Niet om gelijk te krijgen of te hebben.
Ik heb een enorm respect voor Pascal.
Die doet waarschijnlijk programmeren als beroep, wie ben ik dan om als hobby-ist hem voor te schrijven wat hij moet doen of laten.

Vaak zitten oplossingen juist in de kleine dingen die we over het hoofd zien.
En Dev...
Wellicht komt het vaker/soms over dat ik een "betweter" ben.
Maar dit is absoluut niet mijn bedoeling. Ik ben gewoon enorm enthousiast over Linux.
Neem mij dit niet af. Laat mij in m'n waarde, net als ik bij jou doe!

Gr. Masy

Ik wil hier geen strijd, met niemand. Ook niet met jou...

13

Re: sockets open gehouden door dochter process ?

Vergeten te vermelden, maar ERG belangrijk:

Ik heb Windows begin dit jaar compleet/totaal "afgezworen". Linux (Mint) is volwassen geworden...
Windows (XP/7 en 10) draait bij mij onder Virtualbox (https://www.virtualbox.org/)
Heb daarvoor speciaal een nieuwe PC gekocht (8 gb RAM, 256 gb SSD schijf)

Mijn pascal programma's test ik hier virtueel uit. Als je systeem ingrijpend programmeerd, raad ik je aan dit
virtueel te doen...
Gaat 't mis heb je binnen 5 minuten de zaak middels een backup hersteld.
De tijd die er nodig is om 20 GB (Windows 10) te copiëeren, meer niet...

Mijn ervaring is dat als je binnen een bestaande Linux omgeving programma's doet testen en het gaat mis, je veel meer tijd aan herstellen kwijt bent. En héél veel ergernis. Dus NOOIT testen binnen een bestaande omgeving...

Virtualbox kan alles aan: Ook (L)UNIX server omgevingen.
Installeren dus: VBox zit ook standaard binnen de repo's van de Debian/Ubuntu/Mint versies...

Greetings Masy...

14

Re: sockets open gehouden door dochter process ?

Vijf minuten en Windows?

Met Vagrant doen we dat sneller: https://asciinema.org/a/5tro51qv5jlb7oghpxnoly6sm

ACAB: All computers are broken. https://medium.com/message/everything-i … e5f33a24e1 "I've decided that you need gray hair and hemorrhoids to be a consultant.
The gray hair makes you look distinguished & the hemorrhoids make you look concerned."

15

Re: sockets open gehouden door dochter process ?

Nou, het klinkt wel een beetje als een brugpieper die denkt dat de leermeester op zijn/haar denkniveau zit wink

Denk dat als je wilt helpen, je dat minder wollig moet doen, gewoon als je een hint weet, gewoon die hint geven en meer niet. Het kan inderdaad zo zijn dat Pascal iets simpels over het hoofd ziet, maar ik betwijfel dat hij daar op deze manier achter komt wink

Help mee om KDE 5 in het Nederlands te vertalen!!

16

Re: sockets open gehouden door dochter process ?

Verder graag on-topic.

Help mee om KDE 5 in het Nederlands te vertalen!!

17

Re: sockets open gehouden door dochter process ?

@Devtroll

Geweldig toch? Ik leer weer van jou...

En zo moet het gaan op dit forum: Elkaars ervaringen uitwisselen.
Ik betwist jouw gelijk hierin niet, maar volg en ontdek jouw post...

Gr. Masy

18

Re: sockets open gehouden door dochter process ?

Sorry Rinse,

Mijn laatste post was iets eerder uitgegaan dan jouw "on-topic" melding.
Mijn excuses daarvoor.

Vind het trouwens jammer dat jij een reactie namens Pascal geeft.
Ik weet wat mij te doen staat...
Sucses verder met jullie forum.

Gr. Masy

19

Re: sockets open gehouden door dochter process ?

Ik spreek niet namens Pascal, ik modereer enkel.
En dat doe ik met de zachte hand, zoals je merkt..

Help mee om KDE 5 in het Nederlands te vertalen!!

20 Laatst bewerkt door pascal (17 Jun 2015 18:19:37)

Re: sockets open gehouden door dochter process ?

Rinse schreef:

Maar is dat dan niet de reden waarom de socket open blijft? Doordat B via die socket de request afhandelt?

Neen,
en wel om twee reden niet.
1) B doet helemaal niets met die socket, heeft ehm ook niet nodig.
2) Filehandles worden wel overgedragen naar een thread of een fork maar niet naar een onderliggend programma, waar de telling gewoon weer vanaf 3 begint. (0 stdin, 1 stdout, 2 stderr, 3 eerste file die je opent)
Een socket is gewoon een int die naar een filehandle verwijst. het OS doet de rest.

Masy schreef:

Zoals gezegd, denk ik met je mee. Ik heb "gegoogled" op HP-UX. (Nog nooit van gehoord)
Ik begrijp dat je waarschijnlijk met UNIX programmering bezig bent.

Dat valt me van je tegen Marcel, HP-UX is nu bepaald niet een niche, net zoals Solaris dat niet is.
En ja ik schrijf unix software. Niet heel bijzonder want ik heb dat altijd grotendeels op Linux systemen ontwikkeld en daarna eventueel aangepast voor de betreffende unix versie (en dat zijn er in mijn carriere heel wat geweest).

Masy schreef:

Ik heb Windows begin dit jaar compleet/totaal "afgezworen".

Opmerkelijk. ik heb sinds anderhalve maand eindelijk een toepassing gevonden waar ik Windows voor kan inzetten (Ik hoop dat mijn oude werkgever het ok vind dat ik zijn laptop die hier al twee jaar stond te verstoffen daarvoor inzet icon_redface)
Ik heb zelf nooit iets met Windows gedaan simpelweg omdat ik het gebruikers onvriendelijk en onhandig vind en omdat ik er verder niets mee kan.

On topic
Pascal ziet waarschijnlijk niet iets over het hoofd, maar vraagt zich af hoe sommige zaken op een bepaald systeem geimplementeerd zijn.
Zal eens kijken of ik nog iets van HP-UX boeken heb waarin kernel behavioure beschreven staat.
(het hoef niet per se bij elk OS het zelfde te zijn al ligt dat soort dingen bij UNIX derivaten redelijk vast)

Pascal's Blobfree Homepage
Een dag geen NedLinux is een dag niet geleefd

21 Laatst bewerkt door QzZRBNMdJdsCmwx (17 Jun 2015 21:08:32)

Re: sockets open gehouden door dochter process ?

pascal schreef:

Is dit ergens in de UNIX standaard gedefinieerd ?

Ja. Ten eerste komt elk proces via een fork() tot stand op UNIX. Dus als jij zegt 'de fork van A roept B aan, B heeft niets met A te maken', dat is een contradictie. De enige manier om op UNIX een ander programme uit te voeren is danwel het huidige proces op te offeren, dan wel een fork() van het process te maken en een exec*() functie uit te voeren. Er is dus altijd een relatie tussen A en B, als A of een fork van A B aanroept.

Volgens de UNIX standaard:

The exec family of functions shall replace the current process image with a new process image. The new image shall be constructed from a regular, executable file called the new process image file. There shall be no return from a successful exec, because the calling process image is overlaid by the new process image.

http://pubs.opengroup.org/onlinepubs/9699919799/

De crux zit 'm hier in:

File descriptors open in the calling process image shall remain open in the new process image, except for those whose close-on- exec flag FD_CLOEXEC is set. For those file descriptors that remain open, all attributes of the open file description remain unchanged. For any file descriptor that is closed for this reason, file locks are removed as a result of the close as described in close(). Locks that are not removed by closing of file descriptors remain unchanged.

Na een fork() krijgt een child kopieën van de file descriptors van de parent:

The child process shall have its own copy of the parent's file descriptors. Each of the child's file descriptors shall refer to the same open file description with the corresponding file descriptor of the parent.

http://pubs.opengroup.org/onlinepubs/9699919799/

Als je de file descriptors in de parent sluit, zijn ze (gelukkig) niet automatisch in de child gesloten.

Dus de flow in het programma is (vermoedelijk):

- A luistert op een socket
- Er is een inkomende connectie.
- A forked om de connectie af te handelen het kind A'.
- A' doet iets met de connectie en start dan B (danwel via fork() + exec*(), of alleen een exec(), waar A' effectief B wordt).

Als je file descriptors dan niet close on exec zijn, dan eindigt B inderdaad met de file descriptors van oorspronkelijk A.

Conclusie: of alle file descriptors sluiten voordat je een exec* functie uitvoert. Of beter: FD_CLOEXEC op de file descriptors zetten:

http://pubs.opengroup.org/onlinepubs/9699919799/

Ps. Masy: dit soort posts zijn niet echt productief. Ik moest eerst een muur van tekst doorlezen om te zien dat de discussie uiteindelijk geen stap vooruit is gekomen.

Ps2. Ik zie dat de links niet goed werken omdat de open group site frames gebruikt. Gewoon op die site zoeken naar fork/execve wink.

22

Re: sockets open gehouden door dochter process ?

Daniel, dank.... op zich vertel je niets nieuws maar door alles op een rijtje te zetten worden enkele dingen me wel duidelijker.
Ik heb helaas niet alles zelf in de hand. ik moet sommige functies gebruiken die in een lib zitten
waar ik zelf niets aan mag doen.
Als ik het dan maar weet is het verder geen issue.

Pascal's Blobfree Homepage
Een dag geen NedLinux is een dag niet geleefd

23 Laatst bewerkt door chromisX (17 Jun 2015 22:02:18)

Re: sockets open gehouden door dochter process ?

Het is (denk ik) wellicht een standaard-conventie om bij een forkende daemon veel fd's met O_CLOEXEC te openen (er is een SOCK_CLOEXEC "equivalent" voorhanden om dit b.v. met listener sockets te doen).

Het duppen van een bestaande file descriptor naar een andere "vaste" descriptor (zoals STDIN, STDOUT, STDERR) met 'dup2' voordat je forkt (en in de child gevolgd door een execve) is b.t.w. het mechanisme hoe shells I/O redirection kunnen implementeren. Zie man dup2; wellicht leuk/handig om b.v. alle child STDERRs te laten uitkomen op pipes die in het hoofdproces gelezen en herprint worden met een of ander nummertje (PID) ervoor - "uninterleaved!" smile

24 Laatst bewerkt door QzZRBNMdJdsCmwx (18 Jun 2015 08:09:52)

Re: sockets open gehouden door dochter process ?

chromisX schreef:

Het is (denk ik) wellicht een standaard-conventie om bij een forkende daemon veel fd's met O_CLOEXEC te openen (er is een SOCK_CLOEXEC "equivalent" voorhanden om dit b.v. met listener sockets te doen).

O_CLOEXEC is pas in POSIX 2008 gedefinieerd. Veel open source unices hebben het pas relatief kort, dus het zou me verbazen als archaïsche proprietary Unices het ondersteunen wink.

Het is niet aan mij de Unix-voorvaderen te betwijfelen, maar ik heb het altijd vreemd gevonden dat file descriptors niet standaard close-on-exec zijn (tenzij je ze anders markeert). Het is niet alleen irritant, maar ook een potentieel veiligheidsprobleem.

Volgens mij is men inmiddels ook van deze overtuiging, aangezien de UNIX/C goden inmiddels bijna allemaal bij Go betrokken zijn, en Go close-on-exec doet behalve voor dusdanig gemarkeerde fds:

http://golang.org/src/syscall/exec_unix.go#L17

Zie man dup2; wellicht leuk/handig om b.v. alle child STDERRs te laten uitkomen op pipes die in het hoofdproces gelezen en herprint worden met een of ander nummertje (PID) ervoor - "uninterleaved!"

Hehe, veronderstellende dat je geen nieuw proces start bestaat daarvoor 'tegenwoordig' CSP smile:

https://golang.org/doc/effective_go.html#channels

(De 'P' is hier geïmplementeerd als green threads, en niet als UNIX processen wink.)