Add pid to logging output

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

  • Close this issue

Problem to solve

  • Unicorn workers get killed or die for a variety of reasons, timeouts, memory use, hitting a raise, etc. The goal would be to easily find out what request a worker was operating on when that worker was killed or died.
  • It'd be neat if we had some way to connect an incoming request in our rails/workhorse logs to a pid of the worker that it got assigned too, such that we can search for all requests for that worker pid that got killed by unicorn

Further details

  • Having the ability to search in this format will help us identify the last request going to that worker, to determine signs of problems with specific requests or signs of awkward behavior

Proposal

MVP

  • Add a log field, example: pid that captures the process ID of a worker that received a request

Other Thoughts

  • The challenge would be that normally requests are logged after they've completed, I'm not sure how best to handle said scenario (death of a worker) as it would probably require two logs, one for the incoming request, and then a second containing all the data of the finished request. Perhaps there's a way to prepare the log statement, and prior to unicorn killing a worker, ensuring a log statement gets pushed out as a last ditch attempt to ensure we are able to capture the failed request
  • Potentially, if unicorn decides to kill a worker, we could grab what that worker was churning on, and throw that into the unicorn worker logs?

What does success look like, and how can we measure that?

  • Success to this issue would be knowing how to connect a failed request due to a unicorn worker kill/death, to the request that came in.
Edited Sep 28, 2025 by 🤖 GitLab Bot 🤖
Assignee Loading
Time tracking Loading