My two cents, since I've been using systemd for a while with solr.
Please keep in mind: these are my opinions, not something I'd be angry about :D

On 4/15/20 10:30 PM, Marius Ghita wrote:
> [Unit]
> Description=Apache SOLR
>
> [Service]
> Type=forking
> User=solr
> Environment=SOLR_INCLUDE=/etc/default/solr.in.sh <http://solr.in.sh>
> ExecStart=/opt/solr/bin/solr start
> ExecStop=/opt/solr/bin/solr stop
> Restart=on-failure
> LimitNOFILE=65000
> LimitNPROC=65000
> TimeoutSec=180s
Here's my distribution's [Service] section for comparison:
[Service]
Type=simple
User=solr
Group=solr
PrivateTmp=true
WorkingDirectory=/opt/solr
ExecStart=/opt/solr/bin/solr start -f

To point out the differences:
- I'm starting solr as foreground service, so I don't even need to spec ExecStop, and can use Type=simple instead of forking.
- PrivateTmp to ensure no secrets are world-readable
- Restart=always because I can't tell if failure in solr will always cause an non-zero exit code, so I'd rather be safe than sorry. But that could go in an override as well.

My [Service] overrides:
[Service]
LimitNOFILE=65000
LimitNPROC=65000
EnvironmentFile=/etc/conf.d/solr.env

and the contents of '/etc/conf.d/solr.env':
SOLR_HEAP="14g"
SOLR_DATA_HOME="/storage/solr"
ZK_HOST="solr0,solr1,solr2"
SOLR_HOST=solr0

> We don't need all those Before/After/Conflicts, users can customize further the service via systemd drop-ins I disagree. If you're using systemd everywhere, systemd will also do networking. I don't know what would happen if your network is not set-up, but I'd guess Solr will quit when there's not even a loopback to connect to. I'm in favor for adding "After=network.target" to the [Unit] section.

For the LimitN* you set as default, I'd say that they should go into overrides, not into the default. On the other hand, distributions that package Solr will change the unit file anyways, so I'm not sure how much time we should spend on arguing here :D

Another thing that might be interesting is socket activation.
For those unfamiliar: systemd listens on the port you want to start Solr on. Once a connection comes in, systemd will start the unit and pass the connection on. There's only a few applications that support this (notably nginx) and I'm not sure if lazily starting Solr is a valid use case. I use it, but only for development: I have a Solr container installed and systemd listening on [::]:8983. And if I want to use solr I just connect to port 8983 and systemd will run the container and pass the connection on. Same could work for starting the solr service, but I think that would need some work, so the connection hand-off will work.

best regards,
-1

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to