On Thu, Apr 23, 2015 at 2:53 PM, Tim Bunce <tim.bu...@pobox.com> wrote:
> On Thu, Apr 23, 2015 at 08:21:28PM +0200, Cosimo Streppone wrote:
> > On 23. april 2015 19:02, Tim Bunce wrote:
> >
> > > On Thu, Apr 23, 2015 at 05:59:34PM +0200, Cosimo Streppone wrote:
> > >>
> > >> When the fork + exec'd daemon chooses a random port, I need to be able
> > >> to know which port it has bound itself to, and here lies the problem.
> > >
> > > Perhaps dodge the problem by not picking a random port. Have the parent
> > > process look for free ports itself in some obscure part of the range.
> > > Then pass that port number to the daemon. There's a very small race
> > > hazard here but that seems quite acceptable under the circumstances.
> > > Especially as you'll know you've hit it because the statsd daemon will
> die.
> >
> > Thanks Tim, I can certainly experiment with this idea.
> > My hunch is that port clashes will still happen, but that
> > needs to be verified.
> >
> > >> Basically I set an ENV variable such as $ENV{STATSD_PORT_FILE} with a
> > >> temporary random file name.
> > >>
> > >> In the daemon startup code, if $ENV{HARNESS_ACTIVE} and
> > >> $ENV{STATSD_PORT_FILE} are both there (since the daemon is spawned by
> > >> the *.t script), then the port number is saved into the file name
> > >> indicated by $ENV{STATSD_PORT_FILE}.
> > >
> > > How is "the port number is saved into the file" when you don't know
> > > which port it has bound itself to?
> >
> > The daemon starts and binds using port 0. Still within the daemon code,
> > I can then query for the used port, through regular socket calls.
> > After that, I check for HARNESS_ACTIVE and STATSD_PORT_FILE
> > and I write the port to the file indicated by STATSD_PORT_FILE.
> >
> > Of course I don't like that the statsd daemon code needs to know about
> > this at all.
>
> That approach only applies to your perl statsd, right? For the nodejs
> or C statsd's you don't have an easy[*] a way to find the port.
>
> Tim.
>
> [*] Ignoring options like parsing log output of running lsof.
>
I was about to suggest running `lsof -i -sTCP:LISTEN -p $PID_OF_STATSD` in
the parent after the server has been spawned, when I noticed that Tim
already mentioned the lsof option in his footnote.
Why not use lsof to query the port that was assigned?
Michael
