Re: Apparent timeouts

Viv's analysis of the issue is completely accurate. It is just a symptom of
the GUI thread not getting sufficient run time and thus appearing "frozen",
yet the actual syncing is continuing behind the scenes.


On Fri, 26 Jan 2024 at 12:56, 'Viv Kendon' via unison-users <
[email protected]> wrote:

> I have also seen these timeouts.  I think unison is still working away
> behind them, and it is just the GUI is being slow to respond to a
> request from the desktop system. I have never had to kill the process,
> you can just wait long enough (you can leave the window asking to wait
> or kill as long as you like).
>
> I think it improved with a recent system update, I have not seen it so
> often recently.  Anyway, I think it is just "cosmetic" so to speak in
> the GUI-desktop interaction, and there is no problem underneath with the
> unison processes.
>
> best wishes,
> -- Viv
>
> On 25/01/2024 22:37, John Rose wrote:
> > Thanks for this Greg, Tõivo and Olaf,
> >
> > Please remember in reading my reply that I am about two orders of
> > magnitude less system savvy than you and most of the list participants.
> >
> > I am under Ubuntu 22.04.03 on a new ASUS Vivobook portable, which is a
> > slightly-above-entry-level machine with Core i5 chip, 8 GB of RAM and a
> > 512 GB SSD. My version of Unison is 2.51.5. ASUS says that their port is
> > "USB 3.2 Gen 1" capable of transferring up to 5 Gb/s.
> >
> > As I said before I have never had a similar problem with Unison in the
> > past, even synchronizing on another computer the same approximately 50
> > GB file system with an HDD through a USB 2.0 port (it is of course slow
> > but works fine). The present USB flash drive is a new one made by a
> > reputable company (SanDisk) and has given no problems with simple
> > copying of file systems of several tens of GB. I am synchronizing my
> > /home ext4 partition with a clone on an ext4 partition that I created on
> > the flash drive with gparted.
> >
> > The synchronization with Unison seems to get hung up particularly with
> > two large files of 2.7 and 1.0 GB. If I ask Unison to skip these files
> > it normally synchronizes the rest without problem. If one of these files
> > in in the sync list, Unison gets up to 99% of the file then seems to
> > stay there for at least a minute, then I get a Ubuntu message that the
> > communication with Ubuntu has stopped (I'm using the French Ubuntu
> > interface, could give you the precise wording if useful) and asks me to
> > either wait or quit. When I click "wait" I normally get the same error
> > message back within a few seconds. If I keep pushing the "wait" button
> > the file is sometimes processed after perhaps a half-dozen times, else I
> > push "quit" and re-scan and perhaps it works after a few "wait" button
> > actions.
> >
> > I am right now away from home and not in position to try the USB drive
> > with other computers or the present computer with an external SSD or
> > HDD. I will do this within a couple of weeks, as well as trying to
> > upgrade to Unison 2.53.3, and report back to you.
> >
> > Sorry I don't understand "using the TUI, no -repeat, no fsmonitor". If
> > these are command options, could you give me the command to integrate
> > them into the call from my gnome desktop /*unison-2.51.5+4.13-gtk*/?
> >
> > Thanks again and best regards,
> >
> >      John
> >
> > Le 21/01/2024 à 21:24, Greg Troxel a écrit :
> >> John Rose<[email protected]>  writes:
> >>
> >>> I have been using Unison for about a decade under several Ubuntu LTS
> >>> versions without any major problems. I have just upgraded to a new
> >>> computer using Ubuntu 22.04 LTS.
> >> What version of Unison are you using?   We always recommend updating to
> >> the current release (or later from git master).
> >>
> >>> In the past I have always connected to another computer or to an
> >>> external SSD, but right now I am obliged for a while to synchronize
> >>> with a USB 3.2 flash drive. I find that for large files (several
> >>> hundred MB) I get a message saying Unison has stopped and asking
> >>> whether I want to wait or quit. If I say wait the synchronization
> >>> eventually restarts (sometimes after what seems to be at least a
> >>> minute), and I have to repeatedly say "wait" to complete the
> >>> synchronization.
> >> You don't explain what "restarts" mean or what is issuing that mesage.
> >>
> >> As always, I recommend reducing to the simplest case possible,
> >> specifically using the TUI, no -repeat, no fsmonitor.
> >>
> >> The real question of course is what is going on.   It could be that the
> >> flash drive or the USB port (is it really a USB3 port?) is slow, that
> >> the OS has a bug, that unison has a bug (your report doesn't really lead
> >> me to think that way at all), or that copying data takes a while and
> >> someting about your desktop environment (which is what?) is twitching
> >> and complaining when it shouldn't.
> >>
> >> Also, I'd try rsync of the data to another dir on the flashdrive and see
> >> what happens.  Until you know that the flashdrive and its filesystem
> >> work as you expect, it doesn't make sense to debug anything more
> >> complicate.d.
> >>
> >> You didn't explain what kind of filesystem and what kind of async
> >> options, if any, and if it's journaling.
> >>
> >>> Could something be wrong with my hardware/software system or possibly
> >>> perhaps it's just that synchronizing with a USB flash drive gives
> >>> timeout problems relative to an external SSD (in the past with another
> >> You aren't necessarily having a "Timeout problem".  You could be having
> >> a "buggy complaint of timeout."  But there could be a real issue.
> >>
> >>> computer I connected to an external SSD with a USB 2.0 port and got
> >>> slow transfers but no timeouts)? Is there a set-up parameter to
> >>> increase the timeout threshold or something else to eliminate or
> >>> reduce this problem?
> >> I egrepped the sources quickly and don't find a mechanism like you
> >> experienced.  Please figure out if it's from the desktop environment.
> >
> > --
> > ************
> >
> >                 John B. Rose
> >                 1 Bis rue des Châtre-Sacs
> >                 92310 Sèvres, France
> >
> >                 Email:[email protected]
> >
> > --
> > To unsubscribe from this group and stop receiving emails from it, send
> > an email to [email protected]
> > <mailto:[email protected]>.
>
> --
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
>
>

-- 
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].