Re: fsmonitor on linux is triggered due to unison changes its fingerprint cache

Hello Greg,

thanks for your answer, please see below

On Friday 19 September 2025, Greg Troxel wrote:
> Ulrich Gemkow <[email protected]> writes:
> 
> > We use unison (text UI) to synchronize the homedirs of our users
> > with our file server. We use "-repeat watch" to only start a
> > synchronize run when something is changed in the replicas.
> >
> > In this mode the fsmonitor is triggered about every second by a
> > change in the homedir. Caused by this unison is triggered too.
> > This happens even when the user has nothing changed in the homedir
> > (on both sides).
> >
> > Some digging into this using an inotify watch tool on the file
> > server shows that the trigger is caused by unison itself, which
> > accesses its fingerprint cache (File fp*) about every second.
> >
> > The inotify watch tool shows this sequence about every second:
> >
> > # ~/.unison/homesync/ OPEN fpd51d53afbd71ea49fcec7a981a36e25f
> > # ~/.unison/homesync/ ACCESS fpd51d53afbd71ea49fcec7a981a36e25f
> > # ~/.unison/homesync/ CLOSE_NOWRITE,CLOSE fpd51d53afbd71ea49fcec7a981a36e25f
> > # ~/.unison/homesync/ OPEN fpd51d53afbd71ea49fcec7a981a36e25f
> > # ~/.unison/homesync/ MODIFY fpd51d53afbd71ea49fcec7a981a36e25f
> > # ~/.unison/homesync/ CLOSE_WRITE,CLOSE fpd51d53afbd71ea49fcec7a981a36e25f
> >
> > Please note that the .unison dir is excluded from syncing (but this
> > is not known by the fsmonitor). So nothing is synced, unison on the
> > client side says
> >
> > # Looking for changes
> > #   Waiting for changes from server
> > # Reconciling changes
> > # Nothing to do: replicas have not changed since last sync.
> >
> > which is correct :-)
> >
> > I would expect that the fsmonitor is not triggered when there are
> > no changes in the replicas.
> 
> There's a lot of complexity in "not triggered".  Keep in mind that I
> don't personally use fsmonitor so take this with a grain of salt; I'm
> describing my take because experience says that saying something wrong
> crisply will bring a rapid correction, while expressing that I don't
> know won't lead to a correct and crisp statement :-)
> 
>   - accesses that are read only should be ignored by fsmonitor and not
>     reported to unison
>   - modifications should be reported to unison
>   - unison should examine the reported modfication in light of the
>     ignore list, and if it's to a file that wouldn't be synced, ignore
>     it.
> 
> You are saying "fsmonitor is triggered" but I don't know what that
> means, precisely.  I suggest you enable debugging in fsmonitor and
> unison.

Sorry for not being precise enough. I try to give some background:

In the mode "-repeat watch" unison uses the fsmonitor to watch
(wait) for changes in the replicas. As long as no change happens,
unison waits.

On Linux, the fsmonitor uses the Linux-Kernel inotify interface,
which works (simplified) as follows: The fsmonitor gives the
kernel a list of directories (recursively from a starting dir)
and the kernel adds "watches" on these directories. Then the
fsmonitor calls a blocking system call which returns ("triggers"),
when in one of the watched directories something has changed.
Then fsmonitor itself wakes up unison and gives the changes
information to the calling unison process which looks whether
is has to synchronize the change.

Unfortunately the fsmonitor only receives the root dir of the
replica and adds watches for all subdirs of this replica.
fsmonitor has no knowledge about ignore-Lists. This
simplification in the protocol between unison and fsmonitor
is good, other solutions would be complicate because fsmonitor
would have to translate the ignore lists in the kernel list.

But from this it may happen that unison is waked up
("triggered") also for directories which should be ignored.
This is a small flaw in itself but in most cases no problem.

I will further investigate to answer your other questions
as soon as possible (have to patch the sources).

Thanks again and best regards

-Ulrich

> It sounds like there is a cycle
> 
>   fsmonitor says there is a change
>   unison scans, and rewrites the fp file
>   fsmonitor notices this write

> 
> > This is not a big deal but prevents our notebooks from going in low
> > power mode. A very rough measurement has shown that this is
> > significant on battery life time.
> 
> Sure, it's definitely not what should happen.
> 
> > We use unison 2.53.7 on Linux (Debian 13) using the downloadable
> > package from github for ubuntu. We use ssh as connection method,
> > unison is compiled with ocaml 4.14.2
> >
> > Do other users see the same? Is there an easy solution for this?
> > I do not understand why unison touches its fingerprint cache when
> > nothing changes.
> 
> If unison is told by fsmonitor that something happened, it will rescan,
> and that could result in writing the same data.  You have a good point,
> and perhaps unison should refrain from writing if there isn't a change.
> I am guessing though, that the mod time of the fp file has changed.
> 
> What does ls -lT of the fp file show, over brief intervals?
> 
> It feels like there is a failure of the exclude mechanism to work,
> somehow, in your system setup.  I think the path to resolving this is
> figuring out why that's happening.
> 
> You didn't post your profile (or a sanitized version).

-- 
Ulrich Gemkow
University of Stuttgart
Institute of Communication Networks and Computer Engineering (IKR)