[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Condor-users] condor_schedd listens on ephemeral port despite use_shared_port = true
- Date: Wed, 13 Jun 2012 12:06:53 -0500
- From: Dan Bradley <dan@xxxxxxxxxxxx>
- Subject: Re: [Condor-users] condor_schedd listens on ephemeral port despite use_shared_port = true
On 6/13/12 7:25 AM, Matthew Farrellee wrote:
On 06/12/2012 06:21 PM, Rob de Graaf wrote:
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.
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.