Note that running as foreground has implications on logging that may be surprising compared to current service.
You may want to start a JIRA and a PR/patch at this point, this improvement is a good one! Jan Høydahl > 16. apr. 2020 kl. 16:04 skrev Marius Ghita <ghita.v.mar...@gmail.com>: > > > > 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 >>
