Custom setproctitle

[schlimeszn]

Resolves: #32660

It's a simple refactor with a test to confirm correctness.

[github-actions]

Thanks for contributing to openpilot! In order for us to review your PR as quickly as possible, check the following:

• Convert your PR to a draft unless it's ready to review
• Read the contributing docs
• Before marking as "ready for review", ensure:
  • the goal is clearly stated in the description
  • all the tests are passing
  • the change is something we merge
  • include a route or your device' dongle ID if relevant

[adeebshihadeh]

Doesn't seem to completely work. Name change isn't reflected in htop anymore. Just run selfdrive/modeld/modeld to check.

[schlimeszn]

Doesn't seem to completely work. Name change isn't reflected in htop anymore. Just run selfdrive/modeld/modeld to check.

In $HOME/.config/htop/htoprc set show_thread_names=1

Is this a valid fix? Spent an hour trying to modify the process names in memory with ctypes and no success. Looked at setproctitle source code and would rather flip a bool than steal that

[schlimeszn]

You can also F2 in htop go to Display Options and select Show custom thread names. If you want this change to persist, https://unix.stackexchange.com/a/181370. Or change the config file like I mentioned

[jyoung8607]

The prctl method sets thread names, not the process name. I glanced at the Python setproctitle source, and I agree the method necessary to change the actual process title on Linux seems pretty ugly. If you truly want to change the process title, I don't think it makes much sense for openpilot to roll its own method, just keep using the module.

I think @schlimeszn has proposed a reasonable solution, it's just that AGNOS ships an .htoprc that isn't helping us here. It's configured to show individual threads within processes:

hide_threads=0
hide_kernel_threads=0
hide_userland_threads=0

But with the process name and not the thread name:

show_thread_names=0

I think it may be good to change that regardless. Additionally, it would be nice to be able to name threads within a multithreaded process and then be able to see which threads are consuming CPU in htop.

If we proceed with a thread naming approach, I have some notes:

• An agnos-builder PR should be filed to update the shipping .htoprc
• Rename the functions to reflect setting the thread name as opposed to process name
• When setting, PR_SET_NAME has length and null termination constraints that should be checked
• When reading, use PR_GET_NAME or /proc/PID/task/TID/comm instead of /proc/PID/comm

[adeebshihadeh]

Let's go with what @jyoung8607's outlined. I think this is a reasonable compromise to get rid of a dependency for something that provides minimal value.

[adeebshihadeh]

Reverted on master since test_onroad needs some updates after this. I'll look into this more soon