[
https://issues.apache.org/jira/browse/SOLR-18336?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18143758#comment-18143758
]
Jan Høydahl commented on SOLR-18336:
------------------------------------
A second, independent reproduction of this, from a different trigger, found by
the cross-platform CLI test suite proposed in SOLR-18642 — see [PR
#5323|https://github.com/apache/solr/pull/5323].
{{SslTest.useDifferentHostnameWhenNotCheckingPeerName}} enables Jetty's SNI
host check on a node whose certificate carries only
{{DNS:test.solr.apache.org}}, so every request addressed to {{localhost}} is
refused with {{400 Invalid SNI}}. The node is healthy — its log has {{Started
ServerConnector}} and {{I am the new leader}} for both shards — but {{solr
restart}} exits 1 after 184s:
{code}
Waiting up to 180 seconds to see Solr running on port 29960
ERROR: Solr at null did not come online within 180 seconds!
ERROR: Solr did not start or was not reachable. Check the logs for errors.
{code}
The node's request log shows the probe arriving and being refused every two
seconds, from the moment the connector bound until the timeout — 83 of {{GET
/solr/admin/info/system?wt=javabin}}, all 400. Confirmed by hand on the VM:
{{solr.cmd api --solr-url https://localhost:PORT/solr/admin/info/system}} gives
{{400 Invalid SNI}}, while the same request to {{https://127.0.0.1:PORT/...}}
returns the full JSON.
So it is the same mechanism as the non-loopback-bind case in the description:
the probe is addressed to {{localhost}} while the node is reachable only under
another name. PR #4710, teaching StatusTool the published and bind addresses,
should cover this case too — here the advertised address is {{127.0.0.1}},
which the certificate does cover.
Two details that may be useful. First, it is a {{start}} defect rather than a
{{restart}} one: {{solr.cmd}} rewrites {{restart}} into {{stop}} and falls
through to the shared start path, and plain {{solr.cmd start}} fails
identically under the same configuration.
Second, {{StatusTool.java:304}} interpolates the field {{solrUrl}} where line
299 waited on the local {{pidUrl}}, which is why the message above says "Solr
at null" and never names the URL it was failing against. That cost a separate
investigation here, so it may be worth fixing alongside.
The test is marked {{@AwaitsFix}} against this issue in that PR, so it can be
unmarked when #4710 lands.
🤖 AI Assisted
> Start command waits for all running Solr processes on Windows
> -------------------------------------------------------------
>
> Key: SOLR-18336
> URL: https://issues.apache.org/jira/browse/SOLR-18336
> Project: Solr
> Issue Type: Bug
> Components: cli
> Affects Versions: 10.0
> Reporter: Mikael Sterner
> Assignee: Jan Høydahl
> Priority: Major
> Labels: pull-request-available
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> When using the Solr Control Script to start Solr 10.0.0 on Windows in User
> Managed mode, it checks the status of all currently running Solr instances by
> enumerating the PID files:
> {noformat}
> solr-10.0.0-slim\bin\solr.cmd start --user-managed -p 8981
> Waiting up to 180 seconds to see Solr running on port 8981
> Started Solr server on port 8981. Happy searching!
>
> solr-10.0.0-slim\bin\solr.cmd start --user-managed -p 8982
> Waiting up to 180 seconds to see Solr running on port 8981
> Started Solr server on port 8981. Happy searching!
> Waiting up to 180 seconds to see Solr running on port 8982
> Started Solr server on port 8982. Happy searching!
> {noformat}
> In Solr 9.10.1 it only waits for the specified Solr instance:
> {noformat}
> solr-9.10.1-slim\bin\solr.cmd start -p 8981
> Waiting up to 180 seconds to see Solr running on port 8981
> Started Solr server on port 8981. Happy searching!
>
> solr-9.10.1-slim\bin\solr.cmd start -p 8982
> Waiting up to 180 seconds to see Solr running on port 8982
> Started Solr server on port 8982. Happy searching!
> {noformat}
> This seems like a regression from SOLR-17685, where the simplified
> {{solr.cmd}} script no longer passes in {{--solr-url}} to the status tool
> with commit
> [fd42ecdcd55|https://github.com/apache/solr/pull/3223/changes/fd42ecdcd55f21e8398a0675a6f479b59fc61405].
> (This makes it fall back to waiting for all Solr instances found in the PID
> directory.)
> A naive fix would be to only add {{\-p %SOLR_PORT_LISTEN%}} to the status
> tool, as in commit
> [375b5be8fb3|https://github.com/apache/solr/pull/4710/changes/375b5be8fb3c2e796f79826d89985fda3614585a].
> However, that still feels less robust than {{--solr-url}} as it relies on
> PID files, and it also doesn't work if running with a non-loopback bind:
> {noformat}
> set SOLR_HOST_BIND=10.0.x.x
> set SOLR_HOST_ADVERTISE=myhost.example.com
> solr-10.0.0-slim\bin\solr.cmd start --user-managed -p 8981
> Waiting up to 180 seconds to see Solr running on port 8981
> ERROR: Solr at http://localhost:8981/solr did not come online within 180
> seconds!
> ERROR: Solr did not start or was not reachable. Check the logs for errors.
> {noformat}
> As compared to how it worked before:
> {noformat}
> set SOLR_HOST=myhost.example.com
> set SOLR_JETTY_HOST=10.0.x.x
> solr-9.10.1-slim\bin\solr.cmd start -p 8981
> Waiting up to 180 seconds to see Solr running on port 8981
> Started Solr server on port 8981. Happy searching!
> {noformat}
> Then it correctly passed {{--solr-url http://myhost.example.com:8981}} to the
> status tool.
> Fwiw, adding back the creation of a Solr URL based on {{SOLR_TOOL_HOST}} to
> the script seems to fix the issue:
> {noformat}
> IF NOT "%SOLR_HOST_ADVERTISE%"=="" (
> set SOLR_TOOL_HOST=%SOLR_HOST_ADVERTISE%
> ) ELSE (
> set SOLR_TOOL_HOST=localhost
> )
> ... --solr-url !SOLR_URL_SCHEME!://%SOLR_TOOL_HOST%:%SOLR_PORT_LISTEN%
> {noformat}
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
