Greetings everyone. I would be interested to help transition Solr from SysV to systemd.
Before coming here I've done a rudimentary search on the bug tracker to see systemd related issues. https://issues.apache.org/jira/browse/SOLR-10905 It is a 2017 issue supporting the same change. With a linked systemd service file in the comment section, which I'll come back to.[1] https://issues.apache.org/jira/browse/SOLR-9769 As we would not be calling SysV scripts directly this wouldn't be an issue anymore, as systemd already knows the given service has stopped and wouldn't need to call the ExecStop command anymore. https://issues.apache.org/jira/browse/SOLR-9177 Based on the last comment this issue seems fixed, but not marked as such in the tracker? While not necessarily up there on my list, the advantage of running Solr in the foreground would simplify Solr log access via journalctl While trying out Solr 8.5.0 on CentOS 8 a few days ago I've noticed that there are a couple of hoops one has to jump through to get the service to start via SysV (issues that are just not present with systemd). Systemd generates automated service files as wrappers for SysV scripts, and that's the case for Solr as well. *"Apr 15 12:52:14 localhost.localdomain solr[9084]: /etc/rc.d/init.d/solr: line 75: su: command not found"* The first issue I've had is that for some reason the su command path is not resolved. su is located in /bin and /usr/bin, both are defined in $PATH if I print it out from within the init.d/solr file. Patched manually by specifying an absolute path. Then I had a couple of SELinux violations, for which I had to run a series of systemctl start solr, audit2allow -a -M, semodule -i until I've managed to generate a type enforcement policy that would allow Solr to start. The resulting TE file: module solrsu 1.0; require { type lastlog_t; type su_exec_t; type init_t; class file { execute execute_no_trans getattr lock map open read write }; class passwd rootok; } #============= init_t ============== allow init_t lastlog_t:file lock; allow init_t lastlog_t:file { open read write }; allow init_t self:passwd rootok; allow init_t su_exec_t:file { execute execute_no_trans getattr map open read }; For someone familiar with SELinux they might see that a large part of the policy has to deal with the su execution by an init script. Of course with systemd, none of this SELinux wizardry is required, as - for better or worse - systemd runs with GODMODE cheats. [1] Back to the initial service file, alternatively I propose the following base service file. [Unit] Description=Apache SOLR [Service] Type=forking User=solr Environment=SOLR_INCLUDE=/etc/default/solr.in.sh ExecStart=/opt/solr/bin/solr start ExecStop=/opt/solr/bin/solr stop Restart=on-failure LimitNOFILE=65000 LimitNPROC=65000 TimeoutSec=180s [Install] WantedBy=multi-user.target We don't need all those Before/After/Conflicts, users can customize further the service via systemd drop-ins https://coreos.com/os/docs/latest/using-systemd-drop-in-units.html Specify Type=forking and remove PIDFile. Systemd can guess the PIDFile just fine as Solr spawns a single process. Also, I had issues with the PIDFile and permissions, I didn't want to debug further :) https://www.freedesktop.org/software/systemd/man/systemd.service.html#GuessMainPID= TimeoutSec= set to 180 seconds. Wait for start/stop the same amount in systemd as the solr bin multi-user.target is enough as it's the equivalent of runlevel 3 https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system_administrators_guide/sect-managing_services_with_systemd-targets and graphical.target (runlevel 5) inherits already services of lower targets I've included the LimitNOFILE/LimitNPROC directives, as it is already a suggestion that shows up during startup and why not set up suggested defaults. Is there any opposition to this change? And how can I help to move it forward?
