-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Reducing the necessity for --disable-history
#107
Comments
Honestly, this annoys me from time to time too. Starting up and displaying I think is the right thing to do - with some sort of message that it couldn't gain a lock on the database. I'm not sure I like the idea of racing to get the lock. I anticipate some issues with racing to place the Alternatively, we could add a user interface to start/stop recording at user request with messaging if for some reason a lock couldn't be acquired. |
Frequently, when I open a new terminal session to a machine that's already running zenith from somewhere else, it fails to start, and I have to pass
--disable-history
, which is also a bit long to type.I suggest we could add some smarter behavior for this situation - if zenith detects another instance running, it should still start, and display metrics. This could either mean it starts independently of the database, and perhaps shows an indicator to this effect in the top right. or automatically start reading history, but not writing it.
For the second case, when the other zenith instance is stopped, the current instance could race with any other instance to take ownership of the history db, and keep recording.
The text was updated successfully, but these errors were encountered: