Cryptomator crash log information
To capture crash reports or debug output in Cryptomator, especially when you're troubleshooting a crash like a SIGSEGV or mount failure, here’s how you can dig in:
---
🛠️ Enable Debug Logging in Cryptomator
Cryptomator writes logs to a local file by default. You can find and enhance these logs:
Log File Location
- On Linux:
~/.local/share/Cryptomator/logs/
- On Windows:
%APPDATA%\Cryptomator\logs\
- On macOS:
~/Library/Application Support/Cryptomator/logs/
These logs include stack traces and error messages that are useful for debugging.
Enable Verbose Logging
To increase verbosity, launch Cryptomator with debug flags:
`bash
cryptomator --log-level TRACE
`
Or set the environment variable before launching:
`bash
export LOG_LEVEL=TRACE
cryptomator
`
This will give you more detailed output in the log files.
---
🧨 Capture JVM Crash Reports
If Cryptomator crashes due to a JVM error (e.g., SIGSEGV), it typically generates a file like:
`
hserrpidXXXX.log
`
These are written to the working directory or sometimes alongside the log files. They contain:
- Native stack traces
- Thread states
- Memory usage
- JVM arguments
Look for lines like:
`
Problematic frame: C [libc.so.6+0x4798b]
`
or
`
Thread: "AWT-XAWT" daemon [threadin_native]
`
These can help pinpoint whether the crash is in the graphics stack, FUSE layer, or elsewhere.
---
📡 Real-Time System Logs (Linux)
To monitor system-level events during a crash:
`bash
journalctl -f
`
Run this in a separate terminal while Cryptomator is active. It will show kernel, FUSE, and desktop environment logs that might correlate with the crash.
---
🧩 Additional Tips
- Try switching volume types (FUSE vs WebDAV) to isolate the issue.
- If mount points get stuck after a crash, use:
`bash
fusermount -u /path/to/mount
`
or
`bash
umount /path/to/mount
`
to clean up without rebooting.
- You can also check Cryptomator’s GitHub issues for similar crash reports and JVM config tweaks that might help.
---