How should I investigate this situation?
I have not killed it because I don't know if there will be other problems.
I restarted gitlab but it didn't work.
$ kill 3725346
kill has no effect on it, it seems to restart automatically.
try remove
I want to find the lockgit folder location and delete it.
$ cd /proc/185258ll
$ ll
I can't find the folder



Use
and if need be,
kill -9.Prior to that you might wish to investigate with
ps lp 3725346to learn about its parent, andsudo lsof -p 3725346to see what files it has open. Thelsofutility can also help you find other processes which are holding open a file of interest.Certainly a resident set of > 2 GiB is impressive. Note whether this, or a subsequently restarted git command, allocates that immediately or if the memory footprint slowly grows with time.
EDIT
The pkg source code is at https://github.com/jswidler/lockgit .
Figure out how it is being invoked, both command line args and environment.
Compile it with debug symbols. Invoke under gdb (or
attachgdb to the running, spinning process). Set a breakpoint at main(), then single step through it until things fall apart, same as you'd debug any of your own programs that went astray.In an extreme case, you could arrange for the problematic code to not run at all. For example, chdir to its directory and then
cp -p /usr/bin/true lockgit. It will immediately succeed, with no effect. Which is Bad if you needed it to properly manipulate some secrets, but Good if you just want to move on without the useless spinning process.This might give you a better understanding of what's happening. If it doesn't, then bite the bullet and uninstall lockgit, stop using a program once you find you cannot make it run reliably in your environment.