[dhcp_relay] add retry to checking process dhcprelayd

[Xichen96]

Why I did it

Occasionally, the psutil lib will through error when trying to read name. Retrying fix the problem.

Work item tracking

• Microsoft ADO (number only):

How I did it

Retry the operation

How to verify it

Applied it on production machine and fixed the issue

Which release branch to backport (provide reason below if selected)

• 202305
• 202311
• 202405
• 202411
• 202505
• 202511

Tested branch (Please provide the tested image version)

Description for the changelog

Link to config_db schema for YANG module changes

A picture of a cute animal (not mandatory but encouraged)

[mssonicbld]

/azp run Azure.sonic-buildimage

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[mssonicbld]

/azp run Azure.sonic-buildimage

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[Copilot]

Pull request overview

This PR updates dhcprelayd’s process-checking logic to reduce failures caused by transient psutil exceptions when reading process metadata, aiming to avoid unnecessary dhcp_relay container restarts.

Changes:

• Add a retry loop around psutil process inspection (proc.name() / ppid() / cmdline()) in _check_dhcp_relay_processes.
• Re-raise the last encountered exception after retrying up to 5 times.

[Xichen96]

@yxieca Hi Ying, please help review and merge this pr

[yxieca]

AI agent on behalf of Ying: Reviewed the change in dhcprelayd.py. The retry loop looks reasonable, but consider adding a small backoff sleep between retries to avoid tight looping when psutil hits transient errors. Also consider narrowing the retried exception types (for example AccessDenied vs unexpected exceptions) so we do not mask real bugs. Otherwise looks fine.

[Xichen96]

.
@yxieca Hi Ying

1. we are not masking real bugs, as we will throw out the exception at the end, if retry doesn't help
2. the error we expect to happen doesn't seem to be related to wait time, it's kind of just a random thing. so retry without additional wait time works when patching the production device