Systemd status incorrect on RHEL/CentOS 7, causing fail

[geerlingguy]

In Drupal VM (see geerlingguy/drupal-vm#789), some have noticed that the combo of this role and CentOS 7 results in the following fail:

TASK [geerlingguy.solr : Ensure solr is started and enabled on boot.] **********
fatal: [drupalvm]: FAILED! => {"changed": false, "failed": true, "msg": "Job for solr.service failed because the control process exited with error code. See \"systemctl status solr.service\" and \"journalctl -xe\" for details.\n"}

It looks like the systemctl config for Solr (at least 5.x) might not be configured correctly... going to look into this.

[geerlingguy]

Debug info from journalctl -xe:

Jul 24 03:19:51 centos7test systemd[1]: Starting Session c1 of user solr.
-- Subject: Unit session-c1.scope has begun start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit session-c1.scope has begun starting up.
Jul 24 03:19:51 centos7test su[12809]: pam_unix(su-l:session): session opened for user solr by (uid=0)
Jul 24 03:19:51 centos7test solr[12807]: Port 8983 is already being used by another process (pid: 12603)
Jul 24 03:19:51 centos7test solr[12807]: Please choose a different port using the -p option.
Jul 24 03:19:51 centos7test su[12809]: pam_unix(su-l:session): session closed for user solr
Jul 24 03:19:51 centos7test systemd[1]: solr.service: control process exited, code=exited status=1
Jul 24 03:19:51 centos7test systemd[1]: Failed to start LSB: Controls Apache Solr as a Service.
-- Subject: Unit solr.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit solr.service has failed.
-- 
-- The result is failed.
Jul 24 03:19:51 centos7test systemd[1]: Unit solr.service entered failed state.
Jul 24 03:19:51 centos7test systemd[1]: solr.service failed.

[geerlingguy]

Of course Solr is already running:

$ sudo service solr status

Found 1 Solr nodes: 

Solr process 12603 running on port 8983
{
  "solr_home":"/var/solr/data",
  "version":"5.5.2 8e5d40b22a3968df065dfc078ef81cbb031f0e4a - sarowe - 2016-06-21 11:44:11",
  "startTime":"2016-07-24T03:19:40.136Z",
  "uptime":"0 days, 0 hours, 2 minutes, 21 seconds",
  "memory":"57.3 MB (%11.7) of 490.7 MB"}

[geerlingguy]

Testing with 6.1.0 now... just want to see if it was fixed upstream in the Solr project itself.

[geerlingguy]

With 6.1.0, status works, but when it checks the list of cores, it gives:

TASK [geerlingguy.solr : Check current list of Solr cores.] ********************
fatal: [centos7]: FAILED! => {"changed": false, "content": "", "failed": true, "msg": "Status code was not [200]: Request failed: <urlopen error [Errno 111] Connection refused>", "redirected": false, "status": -1, "url": "http://localhost:8983/solr/admin/cores"}

[geerlingguy]

Disregard the above comment—I was running Java 7, and for some reason things worked differently there. Now 5.x and 6.x are both giving the same error at the same time.

I'm trying a hackish workaround of using service solr stop right after first install to see if we can get Ansible to be able to control the process using the systemd/service module after that.