[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [HTCondor-users] Edgar, your HTCondor shared port question

Hi Todd,

I will try to see how we can update today, and will update here. It is kinda unfortunate that v8.4 is not supported since it is in OSG 3.3 for which the date of end of life support is in May. Hopefully I can get to Condor week this year. 


Edgar M Fajardo Hernandez

On Mar 7, 2018, at 12:21 PM, Todd Tannenbaum <tannenba@xxxxxxxxxxx> wrote:

Hi Edgar,

I did some testing.

I am thinking the strange behavior you are observing below has been fixed along the way since v8.4, since it all works for me as expected with HTCondor v8.6.10 and it does NOT work as expected when using HTCondor v8.4.12. You do know that v8.4 isn't officially supported anymore, right? :)

In a test environment with CCB and shared_port, with HTCondor v8.4.12 condor_tail does not even attempt to access the daemon_sock directory. Behold:

   $ strace condor_tail 4.0 |& grep daemon_sock

But the story look very different (for the better) with HTCondor v8.6.10:

  $ strace condor_tail 5.0 |& grep daemon_sock
stat("/tmp/condor-lock.0.392636214456619/daemon_sock", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
access("/tmp/condor-lock.0.392636214456619/daemon_sock", W_OK) = 0
bind(4, {sa_family=AF_LOCAL, sun_path="/tmp/condor-lock.0.392636214456619/daemon_sock/15273_c6e8"}, 59) = 0
getsockname(6, {sa_family=AF_LOCAL, sun_path="/tmp/condor-lock.0.392636214456619/daemon_sock/15273_c6e8"}, [60]) = 0
getsockname(6, {sa_family=AF_LOCAL, sun_path="/tmp/condor-lock.0.392636214456619/daemon_sock/15273_c6e8"}, [60]) = 0
unlink("/tmp/condor-lock.0.392636214456619/daemon_sock/15273_c6e8") = 0

Best regards and hope to see you end of May at HTCondor Week 2018!

On 3/2/2018 12:15 PM, Edgar M Fajardo Hernandez wrote:
Hi Todd,

Thanks for following up with this. This is a vanilla OSG RPM install
although 3.3 so HTCondor 8.4:

$CondorVersion: 8.4.11 Feb 24 2017 $
$CondorPlatform: X86_64-CentOS_6.8 $

rpm -q condor

So yes condor daemons running as root.

condor_config_val DAEMON_SOCKET_DIR

Well LOCK is in the non standard one because that is the standard gwms



So that is the case in every single glideinwms submit host in the planet.

I tried again after creating the daemon_sock

But still same problem even running condor_tail as root: