Skip to content

[action] [PR:19258] Fix shebang to /usr/bin/python in ansible modules for compatibility#19335

Merged
yejianquan merged 1 commit intosonic-net:202505from
mssonicbld:cherry/202505/19258
Jul 3, 2025
Merged

[action] [PR:19258] Fix shebang to /usr/bin/python in ansible modules for compatibility#19335
yejianquan merged 1 commit intosonic-net:202505from
mssonicbld:cherry/202505/19258

Conversation

@mssonicbld
Copy link
Collaborator

Description of PR

We encountered the following issue when trying to upgrade ansible:
/bin/sh: 1: /usr/bin/env python3: not found
This error occurred when attempting to invoke certain Ansible modules.

According to the Module format and documentation,

image the recommended shebang is: `#!/usr/bin/python`

From the logs, we can observe the following behavior:

  • When the shebang is /usr/bin/env python, Ansible translates it into:
 203 1751357337.89274: _low_level_execute_command(): starting
 203 1751357337.89277: _low_level_execute_command(): executing: /bin/sh -c ''"'"'/usr/bin/env python'"'"' && sleep 0'
  • In contrast, when using /usr/bin/python, Ansible attempts a full interpreter discovery:
 171 1751357179.48738: _low_level_execute_command(): starting
 171 1751357179.48741: _low_level_execute_command(): executing: /bin/sh -c 'echo PLATFORM; uname; echo FOUND; command -v '"'"'python3.13'"'"'; command -v '"'"'python3.12'"'"'; command -v '"'"'python3.11'"'"'; command -v '"'"'python3.10'"'"'; command -v '"'"'python3.9'"'"'; command -v '"'"'python3.8'"'"'; command -v '"'"'/usr/bin/python3'"'"'; command -v '"'"'python3'"'"'; echo ENDFOUND && sleep 0'

This indicates that Ansible treats /usr/bin/env python literally and does not invoke its interpreter auto-discovery logic, leading to failures on systems without the python symlink.

To satisfy the requirements of the latest ansible, we update the shebang lines in all affected modules in advance.

Summary:
Fixes # (issue)

Type of change

  • Bug fix
  • Testbed and Framework(new/improvement)
  • New Test case
  • Skipped for non-supported platforms
  • Test case improvement

Back port request

  • 202205
  • 202305
  • 202311
  • 202405
  • 202411
  • 202505

Approach

What is the motivation for this PR?

We encountered the following issue when trying to upgrade ansible:
/bin/sh: 1: /usr/bin/env python3: not found
This error occurred when attempting to invoke certain Ansible modules.

According to the Module format and documentation,

image the recommended shebang is: `#!/usr/bin/python`

From the logs, we can observe the following behavior:

  • When the shebang is /usr/bin/env python, Ansible translates it into:
 203 1751357337.89274: _low_level_execute_command(): starting
 203 1751357337.89277: _low_level_execute_command(): executing: /bin/sh -c ''"'"'/usr/bin/env python'"'"' && sleep 0'
  • In contrast, when using /usr/bin/python, Ansible attempts a full interpreter discovery:
 171 1751357179.48738: _low_level_execute_command(): starting
 171 1751357179.48741: _low_level_execute_command(): executing: /bin/sh -c 'echo PLATFORM; uname; echo FOUND; command -v '"'"'python3.13'"'"'; command -v '"'"'python3.12'"'"'; command -v '"'"'python3.11'"'"'; command -v '"'"'python3.10'"'"'; command -v '"'"'python3.9'"'"'; command -v '"'"'python3.8'"'"'; command -v '"'"'/usr/bin/python3'"'"'; command -v '"'"'python3'"'"'; echo ENDFOUND && sleep 0'

This indicates that Ansible treats /usr/bin/env python literally and does not invoke its interpreter auto-discovery logic, leading to failures on systems without the python symlink.

To satisfy the requirements of the latest ansible, we update the shebang lines in all affected modules in advance.

How did you do it?

To satisfy the requirements of the latest ansible, this PR updates the shebang lines in all affected modules to #!/usr/bin/python.

How did you verify/test it?

We need to make sure that this change won't affect current test firstly -- test by pipeline itself. And then, we need to make sure that this change works in the new version -- test locally.

Any platform specific information?

Supported testbed topology if it's a new test case?

Documentation

…onic-net#19258)

What is the motivation for this PR?
We encountered the following issue when trying to upgrade ansible:
/bin/sh: 1: /usr/bin/env python3: not found
This error occurred when attempting to invoke certain Ansible modules.

According to the Module format and documentation,

image the recommended shebang is: `#!/usr/bin/python`
From the logs, we can observe the following behavior:

When the shebang is /usr/bin/env python, Ansible translates it into:
   203 1751357337.89274: _low_level_execute_command(): starting
   203 1751357337.89277: _low_level_execute_command(): executing: /bin/sh -c ''"'"'/usr/bin/env python'"'"' && sleep 0'
In contrast, when using /usr/bin/python, Ansible attempts a full interpreter discovery:
   171 1751357179.48738: _low_level_execute_command(): starting
   171 1751357179.48741: _low_level_execute_command(): executing: /bin/sh -c 'echo PLATFORM; uname; echo FOUND; command -v '"'"'python3.13'"'"'; command -v '"'"'python3.12'"'"'; command -v '"'"'python3.11'"'"'; command -v '"'"'python3.10'"'"'; command -v '"'"'python3.9'"'"'; command -v '"'"'python3.8'"'"'; command -v '"'"'/usr/bin/python3'"'"'; command -v '"'"'python3'"'"'; echo ENDFOUND && sleep 0'
This indicates that Ansible treats /usr/bin/env python literally and does not invoke its interpreter auto-discovery logic, leading to failures on systems without the python symlink.

To satisfy the requirements of the latest ansible, we update the shebang lines in all affected modules in advance.

How did you do it?
To satisfy the requirements of the latest ansible, this PR updates the shebang lines in all affected modules to #!/usr/bin/python.

How did you verify/test it?
We need to make sure that this change won't affect current test firstly -- test by pipeline itself. And then, we need to make sure that this change works in the new version -- test locally.
@mssonicbld
Copy link
Collaborator Author

Original PR: #19258

@mssonicbld
Copy link
Collaborator Author

/azp run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@yejianquan yejianquan merged commit 85e9f58 into sonic-net:202505 Jul 3, 2025
14 of 17 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants