Re: [Condor-users] condor_schedd listens on ephemeral port despite use_shared_port = true

[Dan Bradley <dan@xxxxxxxxxxxx>]

On 6/13/12 7:25 AM, Matthew Farrellee wrote:
> On 06/12/2012 06:21 PM, Rob de Graaf wrote:
> > Hi,
> >
> > My central manager host is configured to use a shared port:
> >
> > USE_SHARED_PORT = TRUE
> > SHARED_PORT_ARGS = -p 9618
> > COLLECTOR_HOST = $(CONDOR_HOST)?sock=collector
> > DAEMON_LIST = COLLECTOR, MASTER, NEGOTIATOR, SCHEDD, STARTD, SHARED_PORT
> >
> > I expected daemons would only be listening on that one port, but I see
> > the condor_schedd still binds to an ephemeral port as well:
> >
> > # lsof -a -i4 -p `pidof condor_schedd`
> > condor_sc 3916 condor 9u IPv4 15171 0t0 TCP *:42616 (LISTEN)
> > condor_sc 3916 condor 10u IPv4 15172 0t0 UDP *:42616
> >
> > I set SCHEDD_DEBUG = D_PID D_FULLDEDUG D_NETWORK D_COMMAND and I can see
> > the scheduler getting a file descriptor:
> >
> > 06/12/12 23:56:57 (pid:3916) LISTEN <192.168.1.123:42616> fd=9
> >
> > I haven't found any sign that this fd=9 is actually read from or written
> > to. Remote hosts can query the schedd on the shared port. Firewalling
> > the "extra" port doesn't seem to break anything. Is the condor_schedd
> > supposed to be listening to an ephemeral port even if use_shared_port =
> > true? What's it for? This is condor version 7.8.0.
> >
> > Thanks!
> >
> > Rob
>
> That's likely the port the condor_schedd maintains to communicate with 
> condor_shadows. Why it isn't bound to loopback is a good question.

Yes.  That is what it is.  All communication on this port will be local 
to the schedd machine, since the shadows run locally.

It could be bound to loopback.  A tweak would be needed to make this 
work out-of-the-box with the default security policy.

To cause the schedd to use loopback, I think you could set 
SCHEDD.NETWORK_INTERFACE = 127.0.0.1 and 
SCHEDD.BIND_ALL_INTERFACES=False.  I haven't tested to see what else you 
might need to tweak.

--Dan