On Oct 7, 2020, at 7:28 PM, Bryan Davis <bd808@wikimedia.org> wrote:

This may actually be the root of some of your frustrations. Toolforge
is not meant to be a replacement for a development environment on your
local laptop or other server.

Hmmm. That's not the impression I got from reading what's available on wikitech. It's called a "developer account". Pages like https://wikitech.wikimedia.org/wiki/Portal:Toolforge/About_Toolforge say things like, "If you already know these basics, then you are ready to start developing tools!" So, it sure sounds like it's supposed to be a development environment.

And https://wikitech.wikimedia.org/wiki/Help:Toolforge/Developing_successful_tools says:

Pick the right development environment
If you will be doing heavy processing (e.g., compiles or tool test runs), please use the development environment (dev.toolforge.org) instead of the primary login host (login.toolforge.org) so as to help maintain the interactive performance of the primary login host.

which is at odds with your statement that it's not meant to be a development environment. Yes, I keep several tmux sessions nailed up. It makes life easier and I assumed it would be a very small impact on the system. As for:

a python process that appears to be some sort of TCP log event sync.

That's exactly what it is. Tailing a NFS log file is not practical. I opened a phab ticket on this which got triaged to a low priority. Fair enough, so I found a workaround. The process you're seeing is essentially a private syslog server I'm running. My k8s web server process logs to that, bypassing NFS. I don't need that running when I'm not actively debugging, so I'll shut it down now. It didn't seem like the kind of thing that would be imposing any significant load.