[
https://issues.apache.org/jira/browse/SOLR-6734?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16507061#comment-16507061
]
Shawn Heisey commented on SOLR-6734:
------------------------------------
I know that logically, it makes a lot of sense to have the agent be the only
piece that the system init handles.
But then we have to answer the question of what we should do if a novice types
'service solr stop'. I think a novice would expect that this will only stop
Solr, not everything. But if the agent is the only thing handled by the
system, the pedantically correct thing to do would be to kill ZK, kill Solr,
and kill the agent. If we were to name the service "solr8-agent" when the
given service name during install is "solr8", that would eliminate the
confusion, but I know I would not be happy to have an installation program use
something different for the service name than EXACTLY what I told it to use.
Another possibility, one that I like more as I imagine how it would work, is to
configure multiple service names for the OS, but have them call the
script/agent with different options. If the name given during install is
solr8, then we create solr8, solr8-all, and solr8-zk, with only solr8-all
configured for startup and shutdown. If the user types 'service solr8 stop'
then ONLY Solr will be affected - the agent will stay running, and so will ZK
if it is configured. Similarly, 'service solr8-zk stop' would only affect ZK,
not the agent or Solr. For both solr8 and solr8-all, the start action will
produce identical results -- any of the services that isn't running and is
configured will be started. For solr8-zk, the start action will be slightly
different. It will only take action if ZK is configured to run, and it will
only concern itself with starting ZK and the agent, not Solr.
A detail that may not be obvious from what I've said so far: I want to make it
so that the user can use bin/solr directly for everything, including
start/stop, even when Solr is installed as a service. Right now, if a user
installs a service named 'solr7' with the installer script, I don't think they
can use bin/solr directly for much of anything. If the service name is left at
default, then bin/solr will probably work, because it is hard-coded to check
for /etc/default/solr.in.sh. I have not verified that this is the case, but I
believe it is.
If there is only one service associated with the /opt/solr-X.Y.Z directory
(such as the 'solr8' name mentioned before), then bin/solr will assume that
service. So there needs to be a text file in the program directory that just
lists names of services. If there are multiple services (where things like
/opt/XXX and /opt/YYY are symlinked to that directory), and a service name
wasn't provided, then the command would fail, and the error message would
describe how to indicate which service to act on.
It would also be really awesome if there was a service uninstall option. Not
sure if it should automatically delete /opt/solr-X.Y.Z if the last service has
been removed ... thinking maybe it shouldn't, but should output a message
telling the user how to get rid of that last remnant if that's what they want
to do.
> Standalone solr as *two* applications -- Solr and a controlling agent
> ---------------------------------------------------------------------
>
> Key: SOLR-6734
> URL: https://issues.apache.org/jira/browse/SOLR-6734
> Project: Solr
> Issue Type: Sub-task
> Reporter: Shawn Heisey
> Priority: Major
>
> In a message to the dev list outlining reasons to switch from a webapp to a
> standalone app, Mark Miller included the idea of making Solr into two
> applications, rather than just one. There would be Solr itself, and an agent
> to control Solr.
> http://mail-archives.apache.org/mod_mbox/lucene-dev/201305.mbox/%3C807476C6-E4C3-4E7E-9F67-2BECB63990DE%40gmail.com%3E
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
