Playbook hanging on kernel update

[ammu...@gmail.com]

I've written the following playbook that seems to work perfectly, except when I comment out the kernel update task. Hopefully nothing that I've just missed from the docs.

---
- name: system updates
  hosts: production
  remote_user: ansible
  sudo: yes

  tasks:
    - name: install kernel updates
      action: yum name=kernel* state=latest
      # If there are any updates, we register the below
      # This will trigger a reboot
      register: kernelup

    - name: install other updates
      action: yum name=* state=latest
      register: kernelup

    - name: reboot the system
      command: reboot
      when: kernelup.changed

    - name: wait for ssh to come back up
      local_action: wait_for host={{ ansible_fqdn }} port=22 delay=120 timeout=900 state=started
      when: kernelup.changed

    - name: restart services
      service: name=sendmail state=restarted

The other updates work fine so I'm not sure what could be causing the issue.

Also, is there a way to embed the encrypted password for the ansible account somewhere secret somewhere rather than having to enter the sudo password all the time? Not sure what is best practice with Ansible?

Thanks in advance.

[Petros Moisiadis]

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/8410ae09-8af1-409c-a444-2cfd5cf635a1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

It seems that you should register 'kernelup' only for the first task, not twice.

[Allan Mullan]

Sorry, that was left in after I tested commenting out the Kernel update task. That isn't in the script that is failing.

You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/8410ae09-8af1-409c-a444-2cfd5cf635a1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

It seems that you should register 'kernelup' only for the first task, not twice.

--
You received this message because you are subscribed to a topic in the Google Groups "Ansible Project" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ansible-project/ygoE8zpQMlg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ansible-proje...@googlegroups.com.

To post to this group, send email to ansible...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/539F1227.70609%40yahoo.gr.

For more options, visit https://groups.google.com/d/optout.

--

Allan Mullan
e: AMMu...@gmail.com | m: +44 (0)7 4269 78476

[Christian Rusa]

Maybe I get something wrong, but why do you register kernelup for the "other updates"?

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CADnEW0%3DwbvOb4s3BAiikbHLqVsWee6HQ5ikoaUgC%2BDYwK6UdZg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

-- 
toscom - the open source company

Christian Rusa
Breiteneckergasse 32                    1230 Wien
Mobil: 0699 10205595                    Fax: 01 9249633
www.toscom.at                           christi...@toscom.at 

[Allan Mullan]

No, kernelup is only registered for the kernel update (the first one) - the second kernelup registration was only used to test that it registers and test functionality but is not meant to be there.

Allan Mullan
e: AMMu...@gmail.com | m: +44 (0)7 4269 78476

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/539F13BE.8000406%40toscom.at.

[Michael Peters]

On Mon, Jun 16, 2014 at 11:52 AM, Allan Mullan <ammu...@gmail.com> wrote:
> Sorry, that was left in after I tested commenting out the Kernel update
> task. That isn't in the script that is failing.

Could you try pasting the ansible playbook that is failing (if the one
you pasted isn't it).

[ammu...@gmail.com]

Running the following playbook with: ansible-playbook update_system.yml --limit=production -K

---
- name: system updates
  hosts: production
  remote_user: ansible
  sudo: yes

  tasks:
    - name: install kernel updates
      action: yum name=kernel* state=latest
      # If there are any updates, we register the below
      # This will trigger a reboot
      register: kernelup

    - name: install other updates
      action: yum name=* state=

latest

    - name: reboot the system
      command: reboot
      when: kernelup.changed

    - name: wait for ssh to come back up
      local_action: wait_for host={{ ansible_fqdn }} port=22 delay=120 timeout=900 state=started
      when: kernelup.changed

    - name: restart services
      service: name=sendmail state=restarted

[ammu...@gmail.com]

Have just done a watch on the process list on the server that this is running against and I can now see that it's NOT hanging at all. In fact, what it's doing is running repoquery against all possible kernel packages. Not sure if it's normal for this to take so long but at least I have something to work on.

root     27883 27429 99 13:02 pts/0    00:00:01  |                       \_ /usr/bin/python -tt /usr/bin/repoquery --show-duplicates --plugins --quiet -q --pkgnarrow=updates --qf %{name}-%{version}-%{release}.%{arch} kernel-debug-devel-2.6.18-371.el5.x86_64

[Michael DeHaan]

It needs to run that to know if certain things need to change or not.

You may wish to consider just shelling to yum update *.

It has been discussed in the past if we want to just run the yum command and report if changes were made, though that has historically been against our philosophy of not running commands that can create changes unnecessarily.

--

You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
To post to this group, send email to ansible...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/5d862cee-6317-435e-a713-ac41830e4652%40googlegroups.com.

[Allan Mullan]

That works but the problem is that if a kernel patch is installed I want to restart. Do you know of any play books around that might fulfil this?

You received this message because you are subscribed to a topic in the Google Groups "Ansible Project" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ansible-project/ygoE8zpQMlg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ansible-proje...@googlegroups.com.

To post to this group, send email to ansible...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CA%2BnsWgwXsG7rD7YRwE0hozpSDTmp0Y_kxw7hOBSR0c4rE-VSww%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Michael DeHaan]

I'm not sure.

Perhaps you could register a timestamp of the kernel or the last changed time of the kernel page, run the update, and then use a when statement to see if it changed?

This could be a no-op statement that notified a reboot as the last action in your playbook.

To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CADnEW0k5DeCCv-DD_Nqa4gmXtWMEG_pUOPpR0dpV_rMXu0Ot%3Dw%40mail.gmail.com.