centos7 target - sudden python interpreter trouble

I am running a playbook to install postgresql against a centos7 (python 2.75) target and am getting this error about a bad python interpreter.

I try to solve this via the inventory.yml

all:
hosts:
[hostname]: # centos7
ansible_host: my.domain.org
ansible_user: username
ansible_python_interpreter: /usr/bin/python

(also tried interpreter_python: /usr/bin/python). the error remains though

funny fact … I ran other playbooks successfully against the same host before even without having specified any python interpreter.

any ideas what may be going wrong here?

<snip>

Hi,

Maybe something wrong with alternatives ?

alternatives --list | grep -i python

Regards,

thx for the hint

Maybe something wrong with alternatives ?
> alternatives --list | grep -i python

turns out empty.

have tried to get something working with

alternatives --install /usr/bin/python python /usr/bin/python2.7

(where /usr/bin/python is already a symlink to /usr/bin/python2 which is a symlink to /usr/bin/python2.7). It did not change anything though.

probably it's my incompetence. I never heard about alternatives before (and don't really get it, as I thought the symlinks /usr/bin/python > /usr/bin/python2 > /usr/bin/python2.7) should be sufficient to guide anybody looking for python to the right executable. Neither do I get why all of a sudden a playbook requires this where opther playbooks running against the exact same host haven't.

Running from the same controller server with the same ansible version ?

Regards,

no, I ran all that on the target. doing that on the Ansible controller server I get:

alternatives --list | grep python
python manual /usr/bin/python3
python3 auto /usr/bin/python3.6

That's not what I was asking... But you answer indirectly to one of my questions.
You have only one ansible controller as I understand.

You seems to say that there were some playbooks which works OK and some don't on the same targets.
Do you use the same ansible version for the the one which are OK and not OK ? There were some changes between versions of ansible for the python default interpreter search
Do you use the same inventory ? If not did you force the ansible python interpreter on one and not the other ?

Regards,

>>
>>
>> > thx for the hint
>> >
>> >>
>> >> Maybe something wrong with alternatives ?
>> >> > alternatives --list | grep -i python
>> >
>> > turns out empty.
>> >
>> > have tried to get something working with
>> >> alternatives --install /usr/bin/python python /usr/bin/python2.7
>> >
>> > (where /usr/bin/python is already a symlink to /usr/bin/python2 which
>> > is a symlink to /usr/bin/python2.7). It did not change anything
>> > though.
>> >
>> > probably it's my incompetence. I never heard about alternatives before
>> > (and don't really get it, as I thought the symlinks /usr/bin/python >
>> > /usr/bin/python2 > /usr/bin/python2.7) should be sufficient to guide
>> > anybody looking for python to the right executable. Neither do I get
>> > why all of a sudden a playbook requires this where opther playbooks
>> > running against the exact same host haven't.
>>
>>
>> Running from the same controller server with the same ansible version
>> ?
>
> no, I ran all that on the target. doing that on the Ansible controller
> server I get:
>
> alternatives --list | grep python
> python manual /usr/bin/python3
> python3 auto /usr/bin/python3.6

That's not what I was asking... But you answer indirectly to one of my
questions.
You have only one ansible controller as I understand.

yes, one single controller

You seems to say that there were some playbooks which works OK and some
don't on the same targets.
Do you use the same ansible version for the the one which are OK and not
OK ? There were some changes between versions of ansible for the python
default interpreter search

yes same ansible version, no changes in either ansible version, not python

Do you use the same inventory ? If not did you force the ansible python
interpreter on one and not the other ?

same inventory, no forcing

also I can run ad-hoc commands (like ping) on that target successfully (which should proove to some extend that python can be addressed on target, shouldn't it?)

Is this literally what is in your inventory.yaml file? Is that even valid yaml?
Shouldn't it be:

all:
   hosts:
     hostname: # centos7

this i.e. also works

ansible [hostname] -m shell -a 'yum install @postgresql -y' --become

this is my literal inventory file: https://paste.debian.net/1215386/
it works for other playbooks, it works for ad-hoc commands (where I addresse a particular host from that group)

the '# centos7' comment on 2 targets is legal I believe.
To rule this out I have removed it for a test run. Still the error was present

the '# centos7' comment on 2 targets is legal I believe.
To rule this out I have removed it for a test run. Still the error was present

Somewhere the value /usr/bin/python3 must come from ... try to grep for this string through all relevant directories.

Regards

    Racke

Did you surcharge the python interpreter variable in a config file ? (/etc/ansible.cfg, ~/.ansible.cfg, etc...)

See:
https://docs.ansible.com/ansible/latest/reference_appendices/config.html

Regards,

Can you do:
    ansible [hostname] -m setup

Can you do:
    ansible [hostname] -m setup

yes, that works

Did you surcharge the python interpreter variable in a config file ?

(/etc/ansible.cfg, ~/.ansible.cfg, etc...)

I had a similar idea nad see an 'interpreter_ansible=auto_silent' in my effective ansible.cfg- Turning that off does not change anything though