User still holds db locks despite being disconnected from the database

Process is blocking other users from acquiring a lock on several records.

It has maintained a long-running transaction  for several hours. 

It is consuming approximately 100% of a CPU core.

proshut -C list shows the user as disconnected (D) in all databases.

However, lsof indicates that the process still has database-related files open.

Based on the lock table, the process does not appear to be waiting on another user's lock, nor does it appear to be queued for a lock.

The original parent process is no longer present, and the process has been adopted by init (PID 1).

pstree does not show any child processes that the process appears to be waiting on.

strace shows the process repeatedly reading from a LBI temporary file.

protrace consistently shows the same ABL call stack.

The process is also not responding to kill -15 (SIGTERM).

Process was likely in the middle of a long running transaction when the parent process was terminated.

The transaction went into the rollback phase that would take just as long to undo as the original transition was open for. 

This would explain why the process did not respond to a kill -15 as it was already in the process of terminating gracefully. 

Eventually the process completed the transaction rollback on its own.

In this scenario all that can be done is to wait for the transaction to be undone. 

If the process was terminated with a forceful kill command it would  either not respond or likely bring the db down due to the possibility that it was holding a shared memory resource. 

Upon restart, the database would have to go through crash recovery to undo the transaction and would take just as long.