Reducing the necessity for `--disable-history`
alexmaco opened this issue · comments
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.
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 .lock file. I'm fairly sure the write operation isn't atomic for all file systems. And in some instances even a mv operation isn't. We could look into asking the kernel to lock the file, though this is area of unix programming I'm not experienced in.
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.