Fix pre5 systemd configuration #81
Conversation
Testing Solr on the newer versions of the OSes breaks the Java installation on OSes that do not supported the older version of the package. Since the java role has sensible defaults for various OS versions this simply doesn't set a version so the default is used - except debian 9. Debian 9 doesn't correct get java 8 but 7 is attempted to be installed. So the test still overrides the java package for > debian 8. The apt cache needs to be updated as well due to a behavior difference in the newer version of apt and ansible. It appears that ansible currently incorrectly updates the apt cache in earlier OS versions so the java installs wwere working correctly. In the newer versions, however, trying to install java results in a package not found error due to the empty cache.
Solr 3/4 do not provide the /bin/solr binary to use. Instead they use start.jar file with jetty. This switches to using a simple systemd unit to manage the process without it backgrounding itself. It also stops doing tasks that are useless/unneeded on systems that use systemd.
|
+1 for merging this, I am running various old Solr versions on CentOS 7 and these builds stopped working recently but switching to this branch fixes them again. In the meantime I have added this to my requirements.yml: |
|
Confirming that Solr 4.5.1 is broken in DrupalVM using later Ubuntu images. Can we get this merged? |
|
Ugh, Solr 4.5... how much I hate supporting years-old unsupported releases :P I promise I'll try to take a look at this PR soon. |
| @@ -34,3 +34,9 @@ solr_restart_handler_enabled: true | |||
| # Used only for Solr < 5. | |||
| solr_log_file_path: /var/log/solr.log | |||
| solr_host: "0.0.0.0" | |||
|
|
|||
| solr_use_systemd: > | |||
There was a problem hiding this comment.
There's a newer variable, I forget exactly what it's called, but it can be used as a simple flag to show whether the OS is using systemd or not... I'd rather do that then set up a hash of all these values here.
There was a problem hiding this comment.
Ah, I think it's: https://stackoverflow.com/questions/39394333/how-can-i-tell-which-init-system-ansible-runs-when-i-use-the-service-module/39394420#comment87434402_39394420 (ansible_service_mgr).
| @@ -1,14 +0,0 @@ | |||
| [Unit] | |||
There was a problem hiding this comment.
Is this still used for newer versions? I don't remember at a glance.
| - name: Update apt cache. | ||
| apt: update_cache=yes cache_valid_time=600 | ||
| when: ansible_os_family == "Debian" | ||
| - name: Set Java 8 package for Debian > 8. |
There was a problem hiding this comment.
Needs a blank newline between tasks.
| - name: Update apt cache. | ||
| apt: update_cache=yes cache_valid_time=600 | ||
| when: ansible_os_family == "Debian" | ||
| - name: Set Java 8 package for Debian > 8. |
There was a problem hiding this comment.
Needs a blank newline between tasks.
|
Cleaned up and rebased in #97 |
Currently, installing 3 or 4 is completely broken on a systemd based system (at least, with the default configuration). This adds testing the older versions on newer OSes to the travis build and fixes the systemd configuration. Additionally, it will stops installing the unneeded
/etc/init.d/based configs on a system using systemd.I believe this is a fix for #57 and is an alternative to #56.