> I'm in favor of adding "After=network.target" to the [Unit] section.
You're right, the network.target is a correct dependency to pin in the Unit section. > For the LimitN* you set as default, I'd say that they should go into > overrides, not into the default. I just prefer as little fine tunning as possible when starting out. If it where up to me, I'd cram in as many suggested settings as possible in the service file, for better developer experience. I'm just not that well versed in Solr tunning nowadays to add more, as I haven't been using it since the 4.x days. > I'm starting solr as foreground service, so I don't even need to spec ExecStop and can use Type=simple instead of forking. Sure, a non-forking process has a few advantages. Like journalctl -u solr being able to display process logs, which I've mentioned in my original email. I do not have a strict preference. Whichever option has the least change resistance works for me. One advantage I can think of with a forked service is that you can depend on the solr.service and be sure that once it's up the Solr service is accessible straight away, while the non-forking version might be in a started state but not yet accessible. > PrivateTmp to ensure no secrets are world-readable Sure, can be used as a precautionary measure. Does Solr store private information in tmp files? > EnvironmentFile=/etc/conf.d/solr.env I know you were just sharing your example override, but since Solr already installs /etc/default/solr.in.sh, I think that's the right place for environmental variables. The updated service file that includes some of your suggestions. [Unit] Description=Apache SOLR After=network.target [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=always LimitNOFILE=65000 LimitNPROC=65000 TimeoutSec=180s PrivateTmp=true [Install] WantedBy=multi-user.target On Thu, Apr 16, 2020 at 11:16 AM David '-1' Schmid < david.sch...@vis.uni-stuttgart.de> wrote: > > 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 > >
