Make sure you don’t have two instances running on the same port. Manticore doesn’t prohibit doing it as soon as you have different pid files. In this case your mysql client may be connecting not to the instance you are expecting.
Make sure you run under user
manticore, otherwise there may be a permission issue since systemctl runs under manticore, meaning all the indexes, binlog files etc are also created under user
manticore and can’t be read when created under another user (e.g.
Usually during start process I encounter the error “service start request repeated too quickly, refusing to start”.
To debug it further go through your steps checking what’s in the searchd log after each. Then you should understand what’s going wrong.
Searchd STOP should not exit until it has actually stopped all background work and is ready to quit.
What do you mean by “Searchd STOP”?
Same on startup - you can start it , it may take a minute to replay binlogs but you do not know it as command line has been executed and if that that time you issue command to STOP - it will not stop normally, it will actually create a mess as you are trying to stop a process in the middle of binlog replay.
If you can make a clear reproducible test case please do it and file a bug report on github. We don’t want any mess even when you try to stop an instance which is being started yet, just need to understand how exactly this can be reproduced, so we can think how to fix it.