Dear rsync experts,

I have used rsync (grsync actually) to make backups for years. It has
worked like a charm. I use three USB-HDDs that I rotate between.

Today was the day for yet another backup.

Now rsync hangs after a short while. According to the messages it is
skipping irregular files (conda something or the other) when it stalls.

I get no error messages. It just stops making progress.

The HDD I use has more than 300 GB of free space. When accessing it
manually (using Thunar) it responds normally. I can see that new
files have not been backed up.

I don't use the computer while taking backups.

I upgraded my system earlier today and I am running kernel
7.0.10+deb13-amd64.

Firing up btop I see several rsync instances but none is doing
anything. If I kill the backup process in grsync and close grsync I
see no change in btop. I can kill some, but not all, rsync instances
from btop.

I can't unmount the HDD as an rsync process is accessing it.

I have found this 'help': https://rsync.samba.org/issues.html
I am none the wiser for that as I don't see any correlation to my
experience of using a process and equipment I have used successfully
so many times suddenly fail.

Any help is appreciated.

TIA

/Martin

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Martin Sch””n <martin.schoon@gmail.com> writes:

Firing up btop I see several rsync instances but none is doing
anything. If I kill the backup process in grsync and close grsync I
see no change in btop. I can kill some, but not all, rsync instances
from btop.

What happens when you try to kill them?

I can't unmount the HDD as an rsync process is accessing it.

I have found this 'help': https://rsync.samba.org/issues.html
I am none the wiser for that as I don't see any correlation to my
experience of using a process and equipment I have used successfully
so many times suddenly fail.

Any help is appreciated.

Have a look in the kernel log.

--
https://www.greenend.org.uk/rjk/

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Den 2026-06-01 skrev Richard Kettlewell <invalid@invalid.invalid>:

Martin Sch””n <martin.schoon@gmail.com> writes:

Firing up btop I see several rsync instances but none is doing
anything. If I kill the backup process in grsync and close grsync I
see no change in btop. I can kill some, but not all, rsync instances
from btop.

What happens when you try to kill them?

Nothing. I am ignored :-(

I can't unmount the HDD as an rsync process is accessing it.

I have found this 'help': https://rsync.samba.org/issues.html
I am none the wiser for that as I don't see any correlation to my
experience of using a process and equipment I have used successfully
so many times suddenly fail.

Any help is appreciated.

Have a look in the kernel log.

I restarted the computer with a 6.1.0-something kernel. Then rsync
worked the way I am used to. I have not investigated further so
I don't know if the kernel change really was what made it work.

/Martin

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 1 Jun 2026 14:49:42 GMT, Martin Sch””n wrote:

Now rsync hangs after a short while. According to the messages it is
skipping irregular files (conda something or the other) when it
stalls.

Which files?

It could be helpful to exclude suspect directories from the backup, to
try to narrow down where the problem is happening.

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Den 2026-06-01 skrev Lawrence D?Oliveiro <ldo@nz.invalid>:

On 1 Jun 2026 14:49:42 GMT, Martin Sch””n wrote:

Now rsync hangs after a short while. According to the messages it is
skipping irregular files (conda something or the other) when it
stalls.

Which files?

.conda/pkgs if memory serves.

It could be helpful to exclude suspect directories from the backup, to
try to narrow down where the problem is happening.

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

On 2 Jun 2026 07:58:41 GMT, Martin Sch””n wrote:

Den 2026-06-01 skrev Lawrence D?Oliveiro <ldo@nz.invalid>:

On 1 Jun 2026 14:49:42 GMT, Martin Sch””n wrote:

Now rsync hangs after a short while. According to the messages it
is skipping irregular files (conda something or the other) when it
stalls.

Which files?

.conda/pkgs if memory serves.

Does it work OK if you skip those?

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

Den 2026-06-02 skrev Lawrence D?Oliveiro <ldo@nz.invalid>:

On 2 Jun 2026 07:58:41 GMT, Martin Sch””n wrote:

Den 2026-06-01 skrev Lawrence D?Oliveiro <ldo@nz.invalid>:

On 1 Jun 2026 14:49:42 GMT, Martin Sch””n wrote:

Now rsync hangs after a short while. According to the messages it
is skipping irregular files (conda something or the other) when it
stalls.

Which files?

.conda/pkgs if memory serves.

Does it work OK if you skip those?

Since the backup worked when using another kernel I have focused on
other things for now. I will return to this one when things calm down.

/Martin

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)

If rsync on one ay stalls because of some problem ( you switched off
your laptop while it was tranfering, the space on the receiver fell to
0, ....
Then subsequent days will also stall. Ie, if you find many instances of
rsync sitting there waiting, you need to figure out what the roadblock
is and fix it and kill the whole pileup of versionf of rsync.

This has been true for many years (Ie, I have run into this problems
many years ago). Figure out what is stopping rsync from completion. If
you are using rsnapshop you can look at /var/log/rsnapshot on the
the computer which is running rsnapshot. Do
df
on both machines to see what the state is of the partition memories.

You need to enable logging in rsnapshot
(eg loglevel, logfile, in /etc/rsnapshot.conf)

For example on the backup machine called cable in root crontab
The rsnapshot.conf file tells rsnapshot to save about 5 different
machne's stuff.


#Backups
00 3 * * * if [ -d /backup-22/daily.0 ]; then echo >>/var/log/rsnapshot ; echo daily `date` >>/var/log/rsnapshot.out ; rsnapshot daily 2>>/var/log/rsnapshot.out; if [ "x$?" = "x1" ] ; then mail -s "rsnapshot failed on cable" unruh@fasicle.ubc.ca </dev/null ; else ( rm /backup-22/daily.0/20* ; touch /backup-22/daily.0/`date +\%F_\%R\%Z`); fi; else mail -s " backup-22 directory not mounted on cable-- cryptmount /backup-22" unruh@fasicle.ubc.ca </dev/null ; fi
40 2 1,9,17,25 * * if [ -d /backup-22/daily.0 ] ; then rsnapshot weekly 2>>/var/log/rsnapshot.out; fi
20 2 1 * * if [ -d /backup-22/daily.0 ] ; then rsnapshot monthly 2>>/var/log/rsnapshot.out; else mail -s "Monthly rsnapshot on cable failed--/backup-22 not mounted " unruh@fasicle.ubc.ca; fi
00 2 1 1 * if [ -d /backup-22/daily.0 ]; then rsnapshot yearly 2>>/var/log/rsnapshot.out; else mail -s "Yearly rsnapshot on cable failed-/backup-22 not mounted" unruh@fasicle.ubc.ca; fi
#Remove lines with lchown from rshapshot log-- too many of them
00 4 * * * grep -v lchown /var/log/rsnapshot>/var/log/rsnapshot1; mv -f /var/log/rsnapshot{1,}

Note that the last line is to remove the infinte number of lines sayinng
lchown was used and dumped into the log file. Since I backup thousands
of files, that would produce thousands of lchown entries.

Yu can also tell rsync to save error messges.

On 2026-06-03, Martin Sch””n <martin.schoon@gmail.com> wrote:

Den 2026-06-02 skrev Lawrence D?Oliveiro <ldo@nz.invalid>:

On 2 Jun 2026 07:58:41 GMT, Martin Sch””n wrote:

Den 2026-06-01 skrev Lawrence D?Oliveiro <ldo@nz.invalid>:

On 1 Jun 2026 14:49:42 GMT, Martin Sch””n wrote:

Now rsync hangs after a short while. According to the messages it
is skipping irregular files (conda something or the other) when it
stalls.

Which files?

.conda/pkgs if memory serves.

Does it work OK if you skip those?

Since the backup worked when using another kernel I have focused on
other things for now. I will return to this one when things calm down.

/Martin

--- PyGate Linux v1.5.15
* Origin: Dragon's Lair, PyGate NNTP<>Fido Gate (3:633/10)