Use case or problem
As seen in Obsidian Sync repeatedly restoring deleted files - #6 by CluelessProductivity, persistent Sync logs would be helpful in troubleshooting issues that take place but go unnoticed for some over time. In this case, we look back only to realize the vault fs is more busy than I thought it was, only to realize that previous versions of folders were restored at some point and I do not know why or when and have difficulty reproducing.
Proposed solution
It’s standard practice in the world of system operations and in Linux or Mac ecosystems to have a log file which persists. While some logs are rotated most are not as they rarely grow to be more than a few mb at the worst for userland applications. On the backend we sometimes rotate on a yearly basis and have many log lines per second during failures, so I’ve seen log files of several gigabytes and been thankful to have them so that I could find the root cause.
When you start an application in terminal, you can see much of the logs live, and Obsidian does do this. However, sync does not log there, nor can I find a log file where these outputs are stored for future debugging.
The proposal is that we should have better logging for the sync component that follows these standards, and indeed the whole application (though that is covered in related issue: Persist log files for debugging)
It looks like the electron-log package was developed for just this purpose, so may be a viable option for the solution.
Current workaround (optional)
N/A; currently the logs are lost if you did not know to save them (or to open in terminal for the general application logs)
Related feature requests (optional)
10 Likes
Looks like the electron-log package follows the standard of routing all logs to a single file, with which I am familiar. However, it logs to .config on Linux, which is considered bad practice (I just double checked since I was not familiar with it and thought maybe it was a userland thing). That default should be overridden with /var/log per Linux logging practices.
This would be especially useful on mobile, where app restarts are often forced by the OS’s resource management. That can produce a scenario like:
- Sync problem occurs.
- User switches to web browser to research problem.
- User returns to Obsidan, which must relaunch because it was pushed out of memory by the browser, and finds an empty Sync log.
It would also be useful when the user isn’t sure how to reproduce the problem consistently.
Even saving the last day or week’s worth of logs would be an improvement, and would probably cover most cases. For longer periods, saving only more notable entries like errors and sync conflicts might still be useful.
5 Likes
100% agreed.
I don’t understand why this isn’t the default behavior. I mean, the purpose of a log in to help indentify issues. If the log is gone every time a program is closed, it is oretty much useless. Unless you check your whole log every time before closing the program (and hope the program doesn’t close itself for watever reason).
If the size is an issue, just create a setting for retention policies.
2 Likes
Can we please please also flesh out the sync logs? I just saw a bunch of what appear to be erroneous rejections … but it doesn’t say why.
So the sync log literally just cleared lines during a running session. It’s like it overflowed or something and older logs are gone. I had copied the synclog out to a file, hopped over to the other two computers trying to figure out what files were garbage (luckily there was a computer where Obsidian was not running right now so I turned off wifi and used it as a source of truth), and when I came back to the computer the bad files were being copied to, I found that while there is some time overlap with the logs I had previously copied, and new logs from actions I took while trying to tend to the messed up garden, older logs are gone.
@WhiteNoise I have both sync logs if you need them to find out why logs aren’t even persistent in a single session, but I’d prefer we just adopt good software operations practices and actually have a log… Yet another area where one of us would have already offered PRs with the fixed behaviour if this were open source..
Ok, so the de-synch happened again and I was an idiot and didn’t manually copy the logs out for all my vaults and then my computer lost power… because of the lack of sync logs, I’m now going to have to fallback on my git repo changes and spend more time wasted picking through this mess. Can we PA-LEASE get persistent logs? I’ve been working in software for 20 years and the only time I’ve seen anything that had such bad logging practices was when I used Windows in the 90s.
If I’m having to keep falling back on git and we can’t adopt good software practices here, why am I even paying for sync?