https://pantsbuild.org/ logo
Join Slack
Powered by
what is the `.pids` dir used for? is this somethin...
# general
f
what is the 
.pids
dir used for? is this something that needs to be mounted when docker runs?
w
it stores the information that allows 
pantsd
to find itself… and no, no need to mount it in. containers should fail to connect to any existing instance of pantsd… i think?
(is that container networking dependent…? hm.)
when pants starts up, it will use the pids directory to locate the pid and port of a running pantsd, and attempt to connect to it on 
localhost:${instance_specific_port}
. if you launch a container atop an existing workspace, and networking is configured the right way, it might attempt to connect to an instance of the daemon outside of the container…?
f
I think I'm running into an issue with the default behavior of the Jenkins docker plug-in, which is to mount in the entire workspace directory
Yeah that's what's happening
w
oof. ok.
not including the 
.pids
directory should avoid that… but would you mind filing a bug? that should be straightforward to fix.
…or, actually. one second. there might be an existing issue
@flat-zoo-31952: what does the error look like? like this perhaps?: https://github.com/pantsbuild/pants/issues/10847
ah, yea. i had opened that before parental leave (in https://pantsbuild.slack.com/archives/CGZFJRY85/p1600900310004700): sorry about that.
would you mind adding any other details you have there, and i’ll fix it tomorrow?
(sorry, it’s always tomorrow! this time because we’re catching up post 2.0.0, and there is one more post to prepare)
f
I think so... I'll have to check when I get power back
(sorry, it's always tomorrow! this time because we're catching up post 2.0.0, and there is one more post to prepare)
Dude no need to feel bad about fixing bugs tomorrow. You guys are really responsive. If I have a decent workaround I can live with bugs for years
😅 1
p
at least in my case, this .pids folder is full of errors files. I clean it up from time to time... maybe pants should be doing that instead of me... (FWIW, most of this files are zero bytes)...
w
there is another directory in there if pantsd is in use. 
${buildroot}/.pids/pantsd
contains the metadata i was referencing.
but yea, the exceptions logs are legacy, and could probably be removed.
f
is the location of 
.pids
configurable?
or can i just nuke it between docker runs
a
+1 on this
w
Copy code
--pants-subprocessdir=<str>
  PANTS_SUBPROCESSDIR
  pants_subprocessdir
      default: /Users/stuhood/src/pants/.pids
      current value: /Users/stuhood/src/pants/.pids
      The directory to use for tracking subprocess metadata. This should live outside of the dir used
      by `pants_workdir` to allow for tracking subprocesses that outlive the workdir data.
(located via 
./pants help
and then 
./pants help-advanced global
)
but if this is only in CI, you might consider disabling 
pantsd
until https://github.com/pantsbuild/pants/issues/10847 is resolved
but yes, you can also just nuke the directory: that will cause 
pantsd
to shut itself down.
f
i don't what the advantages or disadvantages of pantsd running are...but nuking that directory before launching my container seems to be working
w
pantsd
is helpful if you’re going to be running a series of commands in the same branch… the more commands, the more helpful.
f
hmmmm so it's less useful in my CI context where I can't keep it running across stages
but more useful on my workstation
w
exactly.
f
thanks
w
@acceptable-guitar-79854: does the above answer your question as well? i’ll still get #10847 fixed tomorrow, but there should be a few workarounds
a
yes @witty-crayon-22786 thanks, my CI is running no pantsd (set in pants.ci.toml) but at some point the server I was running pants on got really slow, as soon as I deleted those directories it got better (I have a windows machine and ssh into a Linux server all the time)
w
oh… interesting. that might be a separate issue. is yours a pure 2.0.0/v2 install, or have you used v1 since clearing that directory?
a
i was using 2.0.0rc1 and never used v1
i don't remember what the number of open files was (I don't have permissions for 
ulimit
)
the server i was using is shared
w
interesting! that sounds like a separate issue… @acceptable-guitar-79854: if you have any more information on it, would you mind filing a separate ticket?
a
i know, my problem was: server got slow, a simple ls took 30 seconds nuked the cache and rm pantsd stuff and everything returned to normal given that the server is shared and i didn't collect much debugging information i am not sure i can open a ticket
this is why i didn't bring it to the slack either, if it happens again i will investigate and raise a ticket
w
ah, got it.
a
thanks for offering to help, i just love how active you guys are
4 Views
Open in Slack
PreviousNext
Powered by