Headless sync sometimes errors "Another sync instance is already running for this vault."

Bug reports
1

Steps to reproduce

obsidian-headless v0.0.6, node 22.

rm -rf ~/.config/obsidian-headless/sync # clear settings and state
rm -rf vault-dir  # remove the vault
mkdir vault-dir
touch -t 198001010000 vault-dir # ensure sync sees the remote vault as newer, so it doesn't delete everything!

echo $MY_VAULT_KEY | ob sync-setup --vault 'My Vault Name' --path 'vault-dir' --device-name 'some-device'  # this works fine

cd vault-dir
ob sync

About 1 in 3 times I run this, I get that error message. I can see vault-dir/.obsidian/.sync-lock exists after it exits, but you can see it’s been fully deleted and re-created.

You can see this is a clean setup with no existing config.

Did you follow the troubleshooting guide? Y

Expected result

It runs sync without error.

Actual result

Randomly, this error happens.

Environment

Ubuntu 20 or 22, Node 22, obsidian-headless 0.0.6.

2

this is happening to me now too. probably related to the github repo issue 4 (can’t paste a link here) it seems like it did randomly finally figure out it had no previous lock anymore though

3

obsidianmd/obsidian-headless/issues/4

4

this is actually very weird is the expectation people will run “ob sync” using cron or on demand, vs. ob sync --continuous?if so should we setup one systemd unit for each vault we want to sync so it’s always running in continuous mode?

5

You can run on in one shot mode or in continuous mode.

The lock still present may indicate that another instance is running, or you killed the previous instance, or it crashed by itself.

6

I think both need to be an option, but if I was using --continuous I’d probably want to use pm2 or systemd (or systemd running pm2!) to keep it running and monitor the process.

But my issue is this happens even when the directory exists and sync has only just been set up - definitely some kind of bug - looks like that github issue is relevant.

It mentions 5 seconds as the expiry time of the lock, so I’m going to try adding a 5 second sleep between running sync-setup and sync, just in case it’s the age of the setup files that affects it.

I’ve added my note on the github issue.