389 server stops after Ansible "hangs up"

[Joshua J. Kugler]

Ansible 2.0.0.2
Control host: Ubuntu 14.04
Controlled host: CentOS 6

So, I've been trying to set up FreeIPA on my CentOS. I was getting really
frustrated because right after ipa-server-install completed successfully, and
I ran /etc/init.d/ipa start, subsequent commands failed. I finally realized
that dirsrv (389 LDAP server) was stopping soon after starting.

Thinking there was something odd in the ipa startup, I started IPA, slept for
30 seconds, and then tried to start dirsrv. That reported that dirsrv was
already running...but then it shut down right away. Logging in to the machine
and starting dirsrv was fine. Starting dirsrv via

ssh <host> "/etc/init.d/dirsrv start"

also worked.

So, I put this in my Ansible command:

shell: /etc/init.d/dirsrv start && sleep 30

The logs show dirsrv start. And stay started. As soon as that sleep 30
expires, however, and ansible "hangs up" the server immediately shuts down.
Same if I try:

command: /etc/init.d/dirsrv start && sleep 30

Same problem if I wrap the thing in a "script:" command.

WHAT would be killing a daemon, started by an init.d script, to shut down
(cleanly, no less) when ansible is done with the command and disconnects. And
the command to start IPA (or just the server, in the case of chasing down the
bug) is followed by other ansible commands for that host, so it's not like
ansible is done with the host when it "hangs up" after the given command.

I am at my wits end. Does anyone have any ideas how to fix or work around it? I
even tried wrapping the init.d/ipa start in a

screen -d -m

session, but that shuts down right away.

Interestingly enough, if I put this in a script:

#!/bin/bash

screen -d -m /etc/init.d/ipa start /etc/init.d/ipa start
sleep 30

And then pass that to the "screen background" process, even though it has gone
into the background, Ansible won't continue until the script ends and the
screen session terminates...but the dirsrv does stop right away! :)

So, something truly weird is going on here. Clearly a bug on the dirsrv side,
but a really weird interaction with ansible and its ssh sessions.

Ideas would be greatly appreciated!

j

--
Joshua J. Kugler - Fairbanks, Alaska
Azariah Enterprises - Programming and Website Design
jos...@azariah.com - Jabber: peda...@gmail.com
PGP Key: http://pgp.mit.edu/ ID 0x73B13B6A

[Joshua J. Kugler]

Looking in the log files, it only shows startup and shutdown. No errors. As I
said, starting it up from a standard ssh session works file. It's only when
it's started by Ansible, then Ansible disconnects that ds389 then shuts down.

j

On Thursday, February 11, 2016 06:51:09 you wrote:
> Hi,
>
> this seems to be a problem with the ds389 service. You should look into the
> log files the dirsrv is writing.
>
> I guess there could be a corrupt schema or some missing/broken
> initialization problem.

> > --
> > 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/72762047.2gWIYo0p4b%40ho
> > sanna .
> > For more options, visit https://groups.google.com/d/optout.

[Brian Coca]

command/shell are not good ways of starting services, setup a init script/system|upstart configuration instead.

But "if you must", add `nohup` to the command as Ansible immediately terminates the tty and the 'daemon' might not have detached yet or detach correctly which can stall/kill the process.

​---------

Brian Coca​

[Joshua J. Kugler]

Thanks for the suggestion. I had been using ansible's 'service' module and
that wasn't working either. I resorted to command/shell modules as a means of
trouble shooting.