Vagrant up fails with default Solr under CentOS 7

[marikomay]

Vagrant up on fresh VM fails with default 5.5.1 Solr/CentOs 7. Here is the error:

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 only fails with CentOs 7 (works fine with Ubuntu).

My system:
OS X Yosemite (version 10.11)
Drupal VM 3.13
Vagrant 1.8.4
VirtualBox 5.0.24
Ansible 2.1.0

[geerlingguy]

Interesting... The test for Solr 6.x on CentOS 7 seems to be passing (for the role itself: https://travis-ci.org/geerlingguy/ansible-role-solr), so either it's something with the older 5.5.1 version or some other config.

Can you log into the VM and run sudo journalctl -u solr to see the full output of what's failing?

[marikomay]

OK, so it looks like port 8983 is already being used by another process? I'm not sure what is using it, since this is a default install. The only change I've made to the config is vagrant_box: geerlingguy/centos7. Here is the output:

Jul 10 03:08:16 drupalvm.dev systemd[1]: Starting LSB: Controls Apache Solr as a Service...
Jul 10 03:08:16 drupalvm.dev su[30658]: (to solr) root on none
Jul 10 03:08:16 drupalvm.dev solr[30656]: Port 8983 is already being used by another process (pid: 30452)
Jul 10 03:08:16 drupalvm.dev solr[30656]: Please choose a different port using the -p option.
Jul 10 03:08:16 drupalvm.dev systemd[1]: solr.service: control process exited, code=exited status=1
Jul 10 03:08:16 drupalvm.dev systemd[1]: Failed to start LSB: Controls Apache Solr as a Service.
Jul 10 03:08:16 drupalvm.dev systemd[1]: Unit solr.service entered failed state.
Jul 10 03:08:16 drupalvm.dev systemd[1]: solr.service failed.

[geerlingguy]

That's quite odd! Can you run one of the following commands and see what service might be running on the port?

$ lsof -i 8983 -S
# or
$ netstat -a | grep 8983

[marikomay]

Here is the output from lsof -i :8983 -S:

COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
java 30452 solr 90u IPv6 66642 0t0 TCP *:8983 (LISTEN)

[geerlingguy]

@marikomay - It looks like Solr is already running somehow—can you visit drupalvm.dev:8983/solr and see if it returns the Solr Admin page? (Or whatever your site's URL is, if it's not drupalvm.dev).

[marikomay]

Strange. drupalvm.dev:8983/solr does return Solr Admin page. I destroyed the box and tried a fresh VM with the same results. I can access Solr Admin page but provisioning fails:

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"}

[geerlingguy]

It could be a CentOS-specific thing. I haven't tested with CentOS 7 and Solr 5 in a month or so, I should try again! I'll try to figure out what's happening.

[marikomay]

Sounds good. I should mention provisioning with Solr 6.1.0 failed as well. It worked with CentOS 6 and Ubuntu, however, so it appears to be specific to CentOS 7 only.

[geerlingguy]

Testing now.

[geerlingguy]

I can definitely reproduce on CentOS 7:

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"}

I'm going to do some poking and prodding on the upstream role to see if I can find a good workaround.

[geerlingguy]

Upstream issue: geerlingguy/ansible-role-solr#33

[geerlingguy]

This should be fixed upstream; it seems it was caused by this not-really-bug-but-not-worked-around-for-RHEL7 thing in Ansible: ansible/ansible-modules-core#915

[geerlingguy]

I'm testing with Drupal VM now (was running tests in a standalone VM).

[geerlingguy]

Just waiting on an upstream role build to complete, then I'll update the role in Drupal VM to 3.1.2, and this should be resolved!

[geerlingguy]

Fixed via the above commit... testing with a variety of OSes locally.

[geerlingguy]

Tested 5.x and 6.x on both Ubuntu 16 and CentOS 7, and upstream role tests are still passing for other supported OSes, so I'm going to mark this as 'closed'.

Hopefully I'll be able to tag a new Drupal VM release in the next day or two, but until then, you can either update the Solr role manually, or pull master.

[geerlingguy]

Hmm... 6.1.0 seems to be failing still on CentOS 7 only (and only on Drupal VM... not in my test environment, not in Docker containers on Travis CI).

Checking the service via systemctl, I get:

tail: cannot open ‘/var/solr/logs/solr.log’ for reading: No s…ectory

[geerlingguy]

Ah nevermind, forgot to also install Java 8, by setting the following in config.yml:

solr_version: "6.1.0"
java_packages:
  - java-1.8.0-openjdk

[marikomay]

Thanks @geerlingguy! I can confirm both 5.x and 6.x are now working on CentOS 7 after updating the Solr role.