Re: Multiple instances of Unison with same profile
Greg Troxel <[email protected]> Sun, 19 May 2024 12:59:28 -0400
| Newsgroups | gmane.network.unison.general |
|---|---|
| Message-ID | <[email protected]> |
Michael von Glasow <[email protected]> writes: >>> Where does Unison place lock files, and what do they refer to (a root, a >>> single file or something else)? >> I see them in ~/.unison and they appear to be named for a pair of roots >> just like ar/fp. > I currently have a longish sync job running between two systems. Either > system has one lk file, however it is 9 months old and its hash does not > match any ar/fp files. That file has not prevented that sync job from > running over the past couple of months. Looks like it has nothing to do > with the sync job in progress, which would mean no .unison/lk* file has > been created for that job. Interesting. You might as well clean up the old lk file. What is the longish job doing? I wonder if while transfering a big file, the archives are not locked, and there is a lock/modify/unlock, esentially a database transaction. I just ran a sync of a big new file and found that during transfer there was no lock, and a while true; ls -l; sleep 1; done did not catch any lockfiles at end. Not a surprise. >> It looks like finding a lock file is fatal, rather than waiting. > > https://urldefense.com/v3/__https://unix.stackexchange.com/a/776555/91283__;!!IBzWLUs!SnKU0t2hgFKQvLie5Z-Ev3kKlCgpPbVme3qhXRb7B7A44dEKjrBc-xc4BXGcoXfBep34-miF7SPg1beaoQ$ suggests that the fatal > error occurs only when Unison tries to update the archives, which is > after it attempts to sync files that have changed. Makes sense, but maybe it should check/error at the beginning. > Also, another answer to my question there suggested an elegant way to > tun Unison periodically while preventing multiple instances of the same > sync job: run it as a systemd service that is started by a timer. The > service is disabled so it will never run until explicitly started (e.g. > by the timer), and will be considered running until sync finishes. Since > starting an already-started service is a no-op, the timer will never > launch a second Unison instance if one is already running. An added > benefit is being able to start sync from a console at any time (by > starting the service manually) and being able to log out while sync is > still running, without interrupting anything. You should get some kind of award for using elegant and systemd in the same sentence, without sarcasm! To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].