burp-users — The main (currently only) mailing list for burp.

Re: [Burp-users] Large file problems?

[Graham K. <gr...@gr...>]

On Thu, Dec 04, 2025 at 08:42:35AM +0000, Mark Stanton wrote:
> On Thu, 2025-12-04 at 09:15 +1100, gr...@gr... wrote:
> > Hello,
> >
> > Thanks for persisting!
> >
> > Is it always the same large file that it gets stuck on?
> >
> > I would try excluding it to see if the backups then become reliable.
> >
> > Then we would have a narrower scope to try to focus on.
>
> Thanks for that Graham.
>
> Yes, I excluded the initial big file but I'm still having the problem.
>
> The server has log messages (from the client, surely)(?) :
>
> WARNING: Will not descend: file system change not allowed
>       /home/mark/.config/evolution: No such file or directory
> WARNING: Will not descend: file system change not allowed
>       /home/mark/.gnupg: No such file or directory
> WARNING: Will not descend: file system change not allowed
>       /home/mark/.local/share/evolution: No such file or directory
>
> The first two are nfs mounted from remote (in fact the same server
> that's doing the backing up, I only have one), but the third isn't.
> They all do exist and I have the client configuration line
>
>       cross_filesystem=/home
>
> un-commented (although also cross_all_filesystems=0).
>
> I (now) don't know about "large", but I think it is always stopping on
> the same file, the one 755 files in to phase 2, going by the "m"s and
> "f"s and their counts.
>
> How do I find which file that is?  At the top of "unchangaed" the next
> file-not-directory listed is very small. At the bottom it's a not very
> large file deep in the cache of my Firefox profile.

(Sorry for slow reply, I also had email problems, and it seems you
figured this out already)

There are two ways I can think of:

*) Wait until the client got to the point where it's stuck, and do an
   'ls -l /proc/<pid>/fd', where '<pid>' is the process ID of the client.
   To find the process ID, do a 'ps auxw | grep burp'.

*) Alternatively, after the backup has errored, look at the 'unchanged' list
   and the 'changed' list, look at the 'phase1.gz' list and deduce how far
   the client has made it through the 'phase1.gz' list.

Re: [Burp-users] Large file problems?

[Mark S. <ma...@st...>]

On Thu, 2025-12-04 at 09:15 +1100, gr...@gr... wrote:
> Hello,
> 
> Thanks for persisting!
> 
> Is it always the same large file that it gets stuck on?
> 
> I would try excluding it to see if the backups then become reliable.
> 
> Then we would have a narrower scope to try to focus on.

I think it's generally around about the same length of time, which
points more to some OS timeout than anything Burp-ish, d'you think?

I did notice that last night's failure again gives the message "Error
in phase 2" and "Phase 2 end" but there was no "Phase 2 being" message
in the cron log.  Perhaps this is the (rsync) log line limit being
breached?  Could that be causing the backup failure too?

Mark

Re: [Burp-users] Not always the same file

[Mark S. <ma...@st...>]

Sorry, misposted.  I've been having email problems.

I've re-posted this in the proper place in the thread.

Mark

[Burp-users] Not always the same file

[Mark S. <ma...@st...>]

I think it's generally around about the same length of time, which
points more to some OS timeout than anything Burp-ish, d'you think?

I did notice that last night's failure again gives the message "Error
in phase 2" and "Phase 2 end" but there was no "Phase 2 being" message
in the cron log.  Perhaps this is the (rsync) log line limit being
breached?  Could that be causing the backup failure too?

Mark

Re: [Burp-users] Large file problems?

[Mark S. <ma...@st...>]

On Thu, 2025-12-04 at 09:15 +1100, gr...@gr... wrote:
> Hello,
> 
> Thanks for persisting!
> 
> Is it always the same large file that it gets stuck on?
> 
> I would try excluding it to see if the backups then become reliable.
> 
> Then we would have a narrower scope to try to focus on.

Thanks for that Graham.

Yes, I excluded the initial big file but I'm still having the problem.

The server has log messages (from the client, surely)(?) :

WARNING: Will not descend: file system change not allowed
	/home/mark/.config/evolution: No such file or directory
WARNING: Will not descend: file system change not allowed
	/home/mark/.gnupg: No such file or directory
WARNING: Will not descend: file system change not allowed
	/home/mark/.local/share/evolution: No such file or directory

The first two are nfs mounted from remote (in fact the same server
that's doing the backing up, I only have one), but the third isn't. 
They all do exist and I have the client configuration line

	cross_filesystem=/home

un-commented (although also cross_all_filesystems=0).

I (now) don't know about "large", but I think it is always stopping on
the same file, the one 755 files in to phase 2, going by the "m"s and
"f"s and their counts.

How do I find which file that is?  At the top of "unchangaed" the next
file-not-directory listed is very small. At the bottom it's a not very
large file deep in the cache of my Firefox profile.

Mark

Re: [Burp-users] Large file problems?

[Brendon H. <br...@qu...>]

It would appear that my last routine backup also had a client time-out with a 
very similar error thrown by the cron job on the client. In my case it 
restarted later in "resume" mode, so that backup eventually finished with no 
further problems.

Notably, though, my client and server are the same machine. I think that rules 
out a hardware issue. I wonder if there's been some change in the underlying 
libraries/kernel that is now triggering this. I'm running Debian Testing on 
this machine, FWIW - that's had some updates lately. Some other machines also 
being backed-up are on Debian Stable, and I haven't noticed any issues on 
those, though I'll have to take a closer look through their logs to be sure...

Best,
Brendon

On Tuesday, December 2, 2025 5:54:33 a.m. Eastern Standard Time Mark Stanton 
wrote:
> It seems my backup is failing while backing up a large file.
> 
> The file is 655Mb on the system being backed up.  The working/data.tmp
> directory on the server has 69Mb of it.  The cron log on the machine
> being backed up has the errors:
> 
> main socket 4: Got network write error)
> main socket 4: network write problem in asfd_do_write_ssl: 5 -
> 110=Connection timed out)
> error:8000006E:system library:tls_retry_write_records:Connection timed
> out:ssl/record/methods/tls_common.c:1942:tls_retry_write_records
> failure)
> 
> What needs to be changed to fix this?
> 
> Mark
> 
> 
> _______________________________________________
> Burp-users mailing list
> Bur...@li...
> https://lists.sourceforge.net/lists/listinfo/burp-users

Re: [Burp-users] Large file problems?

[<gr...@gr...>]

On Wed, Dec 03, 2025 at 04:25:32PM +0000, Mark Stanton wrote:
> On Tue, 2025-12-02 at 18:51 +0100, burp--- via Burp-users wrote:
> >  Hi!
> >   It is hardware (NIC, switch, router, etc) or ISP issue. That was
> > always when I already faced with similar a few times.
> >  I use burp for years, backing up hundred gigabytes daily, also I
> > have large files (10GB+) too. I'm 100% sure that this is not a burp
> > issue.
> > 
> >  Regards.
> 
> Thanks for that.  I don't think it's hardware because I have been using
> this setup for years with no problems.
> 
> I've just run the backup manually and watching the output I've found a
> long delay, at the client not the server, though.
> 
> Phase 2 has started, then there are various "path has vanished"
> messages, the last one at 15:47.  Then there are about 750 "m" and "f"s
> in the 64 to a line pattern and then, in the middle of one of these,
> there's a fifteen minute pause (I was watching).  During this pause the
> disk light on the specific disk on the server flashed, but only a very
> little.  Then at 16:03 the client complained of the network write error
> and then Burp exited.
> 
> How do I track this down further?

Hello,

Thanks for persisting!

Is it always the same large file that it gets stuck on?

I would try excluding it to see if the backups then become reliable.

Then we would have a narrower scope to try to focus on.

Re: [Burp-users] Large file problems?

[Mark S. <ma...@st...>]

On Tue, 2025-12-02 at 18:51 +0100, burp--- via Burp-users wrote:
>  Hi!
>   It is hardware (NIC, switch, router, etc) or ISP issue. That was
> always when I already faced with similar a few times.
>  I use burp for years, backing up hundred gigabytes daily, also I
> have large files (10GB+) too. I'm 100% sure that this is not a burp
> issue.
> 
>  Regards.

Thanks for that.  I don't think it's hardware because I have been using
this setup for years with no problems.

I've just run the backup manually and watching the output I've found a
long delay, at the client not the server, though.

Phase 2 has started, then there are various "path has vanished"
messages, the last one at 15:47.  Then there are about 750 "m" and "f"s
in the 64 to a line pattern and then, in the middle of one of these,
there's a fifteen minute pause (I was watching).  During this pause the
disk light on the specific disk on the server flashed, but only a very
little.  Then at 16:03 the client complained of the network write error
and then Burp exited.

How do I track this down further?

Mark

Re: [Burp-users] Large file problems?

[<bu...@on...>]

Hi!

It is hardware (NIC, switch, router, etc) or ISP issue. That was always 
when I already faced with similar a few times.
I use burp for years, backing up hundred gigabytes daily, also I have 
large files (10GB+) too. I'm 100% sure that this is not a burp issue.

Regards.

02.12.25 11:54, Mark Stanton:
> It seems my backup is failing while backing up a large file.
>
> The file is 655Mb on the system being backed up.  The working/data.tmp
> directory on the server has 69Mb of it.  The cron log on the machine
> being backed up has the errors:
>
> main socket 4: Got network write error)
> main socket 4: network write problem in asfd_do_write_ssl: 5 -
> 110=Connection timed out)
> error:8000006E:system library:tls_retry_write_records:Connection timed
> out:ssl/record/methods/tls_common.c:1942:tls_retry_write_records
> failure)
>
> What needs to be changed to fix this?
>
> Mark
>
>
> _______________________________________________
> Burp-users mailing list
> Bur...@li...
> https://lists.sourceforge.net/lists/listinfo/burp-users

[Burp-users] Large file problems?

[Mark S. <ma...@st...>]

It seems my backup is failing while backing up a large file.

The file is 655Mb on the system being backed up.  The working/data.tmp
directory on the server has 69Mb of it.  The cron log on the machine
being backed up has the errors:

main socket 4: Got network write error)
main socket 4: network write problem in asfd_do_write_ssl: 5 -
110=Connection timed out)
error:8000006E:system library:tls_retry_write_records:Connection timed
out:ssl/record/methods/tls_common.c:1942:tls_retry_write_records
failure)

What needs to be changed to fix this?

Mark

Re: [Burp-users] Each one blames the other!

[Mark S. <ma...@st...>]

On Sat, 2025-11-29 at 11:49 +0100, opendoor wrote:
> given the previous issues, it looks like there is something fishy
> going 
> on your network.
> 
> i would investigate those first

Thanks for that.  What sort of "somethings" would you think?  The
network runs generally well.  I found a potential issue that the DHCP
pool started at <addresses>.02 instead of .100, I have fixed ips in the
0-99 range.  I've restored the "100" floor of the pool and it failed
the same way.

Mark

Re: [Burp-users] Each one blames the other!

[opendoor <th...@op...>]

given the previous issues, it looks like there is something fishy going 
on your network.


i would investigate those first


best regards

Le 28/11/2025 à 16:01, Mark Stanton a écrit :
> I'm getting frequent backup failures, from a different machine than the
> server now.  Each one says "This is probably caused by the peer
> exiting".
>
> How do progress this?
>
> The server log says :
>
> 2025-11-28 02:46:13 +0000: burp[63742] main socket 5: Got network read
> error
> 2025-11-28 02:46:13 +0000: burp[63742] main socket 5: network read
> problem in asfd_do_read_ssl: 5 - 104=Connection reset by peer
> 2025-11-28 02:46:13 +0000: burp[63742] This is probably caused by the
> peer exiting.
>
> while the log on the peer (Asus550) says:
>
> Nov 27 02:46:59 Asus550 CROND[483862]: (root) CMDOUT
> (fmfmfmmfmmfmfmfmm2025-11-27 02:46:59 +0000: burp[483863] main socket
> 4: Got network write error)
> Nov 27 02:46:59 Asus550 CROND[483862]: (root) CMDOUT (2025-11-27
> 02:46:59 +0000: burp[483863] main socket 4: network write problem in
> asfd_do_write_ssl: 5 - 110=Connection timed out)
> Nov 27 02:46:59 Asus550 CROND[483862]: (root) CMDOUT
> (80898658587F0000:error:8000006E:system
> library:tls_retry_write_records:Connection timed
> out:ssl/record/methods/tls_common.c:1942:tls_retry_write_records
> failure)
> Nov 27 02:46:59 Asus550 CROND[483862]: (root) CMDOUT (2025-11-27
> 02:46:59 +0000: burp[483863] This is probably caused by the peer
> exiting.)
>
>
> The server log also notes
>
> 2025-11-28 02:15:03 +0000: burp[63742] WARNING: Will not descend: file
> system change not allowed /home/mark/.config/evolution: No such file or
> directory
> 2025-11-28 02:15:04 +0000: burp[63742] WARNING: Will not descend: file
> system change not allowed /home/mark/.gnupg: No such file or directory
> 2025-11-28 02:15:33 +0000: burp[63742] WARNING: Will not descend: file
> system change not allowed /home/mark/.local/share/evolution: No such
> file or directory
>
> but those files do exist and I do specifically allow the home directory
> to span filesystems.
>
> I'm definitely confused.
>
>
> _______________________________________________
> Burp-users mailing list
> Bur...@li...
> https://lists.sourceforge.net/lists/listinfo/burp-users

-- 
Thomas Constans
Solutions informatiques libres,
   locales et respectueuses de vos
   données personnelles
📞 33(0)6 23 37 87 85
🌐 https://opendoor.fr
🐱 membre du collectif Chatons.org
🐘 https://framapiaf.org/@thomasconstans
🔑 0xBA19745F80410541

[Burp-users] Each one blames the other!

[Mark S. <ma...@st...>]

I'm getting frequent backup failures, from a different machine than the
server now.  Each one says "This is probably caused by the peer
exiting".

How do progress this?

The server log says :

2025-11-28 02:46:13 +0000: burp[63742] main socket 5: Got network read
error
2025-11-28 02:46:13 +0000: burp[63742] main socket 5: network read
problem in asfd_do_read_ssl: 5 - 104=Connection reset by peer
2025-11-28 02:46:13 +0000: burp[63742] This is probably caused by the
peer exiting.

while the log on the peer (Asus550) says:

Nov 27 02:46:59 Asus550 CROND[483862]: (root) CMDOUT
(fmfmfmmfmmfmfmfmm2025-11-27 02:46:59 +0000: burp[483863] main socket
4: Got network write error)
Nov 27 02:46:59 Asus550 CROND[483862]: (root) CMDOUT (2025-11-27
02:46:59 +0000: burp[483863] main socket 4: network write problem in
asfd_do_write_ssl: 5 - 110=Connection timed out)
Nov 27 02:46:59 Asus550 CROND[483862]: (root) CMDOUT
(80898658587F0000:error:8000006E:system
library:tls_retry_write_records:Connection timed
out:ssl/record/methods/tls_common.c:1942:tls_retry_write_records
failure)
Nov 27 02:46:59 Asus550 CROND[483862]: (root) CMDOUT (2025-11-27
02:46:59 +0000: burp[483863] This is probably caused by the peer
exiting.)


The server log also notes

2025-11-28 02:15:03 +0000: burp[63742] WARNING: Will not descend: file
system change not allowed /home/mark/.config/evolution: No such file or
directory
2025-11-28 02:15:04 +0000: burp[63742] WARNING: Will not descend: file
system change not allowed /home/mark/.gnupg: No such file or directory
2025-11-28 02:15:33 +0000: burp[63742] WARNING: Will not descend: file
system change not allowed /home/mark/.local/share/evolution: No such
file or directory

but those files do exist and I do specifically allow the home directory
to span filesystems.

I'm definitely confused.

Re: [Burp-users] Problem trying to backup MacOS Tahoe (26.x)

[Graham K. <gr...@gr...>]

On Wed, Nov 19, 2025 at 06:22:08PM -0900, Joshua J. Kugler wrote:
> So, I've been using Burp on MacOS for a while, and things were going well. I 
> upgraded to Tahoe, and have hit an issue.
> 
> After upgrade, I backed up, and everything went "ok," except for all the files 
> it couldn't access. I disabled SIP (which I had done on my previous version) 
> and tried again.
> 
> Yesterday the scan phase failed with
> 
> error in readdir: Need authenticator
> 
> and today it failed with
> 
> error in readdir: Operation timed out
> 
> even though I'm backing up nothing but /Users.
> 
> When it spits out that error, it's just been going along at full speed. It's 
> not like it hangs for a while, and then "times out." Whatever it hits has a 
> pretty short timeout.
> 
> I've clicked "allow" on all the popups asking for Terminal to have permissions 
> to reach x, y, and z. :)
> 
> This is client 2.4.0 installed via Homebrew.
> 
> Any ideas?
> 
> Thanks!

Hello,

'Need authenticator' is not a message coming from burp itself. It is just
printing what the operating system told it. The prefix of 'readdir: ' means
that it was trying to read a directory.

Therefore, I think the burp client doesn't have the required permissions to
read some directory despite you clicking all the popups.

Maybe you could figure out what directory this is happening on?

On the server side during the phase1 scan, it will append file system entries
to a file called 'phase1' inside /var/spool/burp/<client>/working.

After the backup fails, looking at the end of the file will give you a clue
as to the point in the file system that the backup reached. I think it won't
list the directory that it failed on, but the entries leading up to that ought
to give you a clue.

[Burp-users] Problem trying to backup MacOS Tahoe (26.x)

[Joshua J. K. <jo...@az...>]

So, I've been using Burp on MacOS for a while, and things were going well. I 
upgraded to Tahoe, and have hit an issue.

After upgrade, I backed up, and everything went "ok," except for all the files 
it couldn't access. I disabled SIP (which I had done on my previous version) 
and tried again.

Yesterday the scan phase failed with

error in readdir: Need authenticator

and today it failed with

error in readdir: Operation timed out

even though I'm backing up nothing but /Users.

When it spits out that error, it's just been going along at full speed. It's 
not like it hangs for a while, and then "times out." Whatever it hits has a 
pretty short timeout.

I've clicked "allow" on all the popups asking for Terminal to have permissions 
to reach x, y, and z. :)

This is client 2.4.0 installed via Homebrew.

Any ideas?

Thanks!

j

-- 
Joshua J. Kugler - Fairbanks, Alaska - jo...@az...
Azariah Enterprises - Programming and Website Design
https://pgp.mit.edu/pks/lookup?search=0x68108cbb73b13b6a

Re: [Burp-users] Failure information

[Mark S. <ma...@st...>]

> It makes the programming simpler, just making all connections (even
> over loopback) be network connections.  

O.



> Have you looked to see if you have a firewall configured?  If so,
> maybe disable it as a test during a backup?

Yes, firewalls all over the place.  That would just prevent rather than
timeout, wouldn't it?

There's also SELinux, but again I think that would be prevention. 
Actually I've tried turning it off with no improvement.


> It might also be that you have some process limits in place.  Have
> you
> looked at the limits on the user which runs the burp backups, if it's
> not the root user?  

Yes, it is run as root.


> > > Do you have a firewall setup running with an option to close open
> > > connections that don't send any traffic in an interval?  

Not that I can see.  I'm guessing it's something like that due to a
less rigorous server installation, I just don't know what, or where to
look.

The night before last even the backup for the other machine on the lan
failed too (first time ever) so I turned off librsync on that one and
that made it work last night.


> Good luck!
> John

Thanks.

Re: [Burp-users] Failure information

[John S. <jo...@st...>]

>>>>> "Mark" == Mark Stanton <ma...@st...> writes:

> Thanks for that John.  I don't think so.  It doesn't look like the
> firewall's rules have anything like that there actively.  I'm still
> surprised that two processes on the same machine would go through a
> TCP connection and therefore a firewall, but if Graham says it does,
> well...

It makes the programming simpler, just making all connections (even
over loopback) be network connections.  

Have you looked to see if you have a firewall configured?  If so,
maybe disable it as a test during a backup?  

> Here I'm just wondering about persisting failure information though.

It might also be that you have some process limits in place.  Have you
looked at the limits on the user which runs the burp backups, if it's
not the root user?  

>> Do you have a firewall setup running with an option to close open
>> connections that don't send any traffic in an interval?  

Good luck!
John

Re: [Burp-users] Failure information

[Mark S. <ma...@st...>]

Thanks for that John.  I don't think so.  It doesn't look like the
firewall's rules have anything like that there actively.  I'm still
surprised that two processes on the same machine would go through a TCP
connection and therefore a firewall, but if Graham says it does,
well...

Here I'm just wondering about persisting failure information though.

> Do you have a firewall setup running with an option to close open
> connections that don't send any traffic in an interval?  
> 
> John

Re: [Burp-users] Failure information

[John S. <jo...@st...>]

>>>>> "Mark" == Mark Stanton <ma...@st...> writes:

> My "timeout" failure has been resolved, doesn't seem to be anything to
> do with Burp itself.

> Now Burp is working I want to resolve the (OS) issue that caused the
> problem. The first question I'm going to get asked is "what does the
> error log say?", but the successful backup has erased all that
> information.  The system log contains a very generic failure message.
> The Burp "Working" directory did have a log with the specific error in
> it, but now a backup has completed it no longer exists and there
> doesn't seem to be a persistent record of those backups that failed.

> Am I just not looking in the right place (if so where is it), or would
> it be helpful if Burp persisted a record of those failures, at least in
> line with the way the successful ones are kept?

Do you have a firewall setup running with an option to close open
connections that don't send any traffic in an interval?  

John

[Burp-users] Failure information

[Mark S. <ma...@st...>]

My "timeout" failure has been resolved, doesn't seem to be anything to
do with Burp itself.

Now Burp is working I want to resolve the (OS) issue that caused the
problem. The first question I'm going to get asked is "what does the
error log say?", but the successful backup has erased all that
information.  The system log contains a very generic failure message.
The Burp "Working" directory did have a log with the specific error in
it, but now a backup has completed it no longer exists and there
doesn't seem to be a persistent record of those backups that failed.

Am I just not looking in the right place (if so where is it), or would
it be helpful if Burp persisted a record of those failures, at least in
line with the way the successful ones are kept?

Mark

Re: [Burp-users] Timeout?

[Mark S. <ma...@st...>]

Ok, that seems to have worked.
I ran a backup from the command line and it finished!
I was a little surprised that the command returned within about fifteen
minutes saying the backup had finished although it clearly hadn't.  The
log gave the finish time about half an hour later.

Now to find out what's wrong with the Fedora setup.

Thanks for your help Graham.

Mark

On Mon, 2025-11-17 at 07:56 +0000, Mark Stanton wrote:
> Ah, thanks.  I looked for librsync in the conf files but couldn't see
> it.  Using that command shows that it is switched on.  I'll turn it
> off
> and see what happens.
> 
> I'm guessing this points to a problem with the server setup, I
> created
> it from a "live" disk, which, it seems, is not as good as a "full
> install".  I'm hoping it's not because the burp server is now version
> 3
> not 2.
> 
> Mark
> 
> On Mon, 2025-11-17 at 08:37 +1100, gr...@gr... wrote:
> > burp -t -c /etc/burp/burp-server.conf | grep librsync
> 
> 
> _______________________________________________
> Burp-users mailing list
> Bur...@li...
> https://lists.sourceforge.net/lists/listinfo/burp-users

Re: [Burp-users] Timeout?

[Mark S. <ma...@st...>]

Ah, thanks.  I looked for librsync in the conf files but couldn't see
it.  Using that command shows that it is switched on.  I'll turn it off
and see what happens.

I'm guessing this points to a problem with the server setup, I created
it from a "live" disk, which, it seems, is not as good as a "full
install".  I'm hoping it's not because the burp server is now version 3
not 2.

Mark

On Mon, 2025-11-17 at 08:37 +1100, gr...@gr... wrote:
> burp -t -c /etc/burp/burp-server.conf | grep librsync

Re: [Burp-users] Timeout?

[<gr...@gr...>]

On Sun, Nov 16, 2025 at 04:35:26PM +0000, Mark Stanton wrote:
> Thanks for that Graham,
> 
> On Sun, 2025-11-16 at 23:50 +1000, Graham Keeling wrote:
> > That sounds a bit strange.
> > Are you able to paste these lines here?
> 
> >From "unchanged"
> 
> t0028t/etc/NetworkManager/NetworkManager.conf
> r003FPwA BhOUH IGk B A A A jX BAA I BpFgGM Boq6eA BpDjuw A A J A A A
> f0027/etc/NetworkManager/NetworkManager.conf
> x00252263:1d20f45a4ba870f9168cea04a711e40e
> t00110000/020B/2C0F.gz
> r003FPwA BhOUH IGk B A A A jX BAA I BpFgGM Boq6eA BpDjuw A A J A A A
> m0027/etc/NetworkManager/NetworkManager.conf
> x002386:ac13a9924203fb4478812ea41bf364c4
> t0020t/etc/PackageKit/PackageKit.conf
> r003FPwA BBkxP IGk B A A A LC BAA I BpFuZk BoB/XX BpDjus A A J A A A
> f001F/etc/PackageKit/PackageKit.conf
> x0024706:71da11578968301072133d233e91cd1e
> t00110000/020B/2C10.gz
> r003FPwA BBkxP IGk B A A A LC BAA I BpFuZk BoB/XX BpDjus A A J A A A
> m001F/etc/PackageKit/PackageKit.conf
> x002368:8c5af1fef19741200dc23ac012d3108b

This is fine, the first 4 lines are for the file itself and standard
attributes. The 4 lines after that are for extended metadata.

> "Changed" similarly has conf files tripled.  Other files aren't tripled
> in either place, probably unsurprisingly.
> 
> > Another question: do you have librsync on or off?
> 
> I'm going to have to claim ignorance here.  I'm a programmer, but not a
> very system-savvy one.  Where would I find an on/off switch for this? 
> This server is running Fedora 43, it's got rsync loaded.

I'm talking about a burp config.
You can use the burp client to show you current configs with

burp -t

So, to show client configs:

burp -t -c /etc/burp/burp.conf

To show server configs:

burp -t -c /etc/burp/burp-server.conf

To show server configs once a particular client has connected:

burp -t -c /etc/burp/burp-server.conf -C testclient


The librsync option is a server-side option, so to see what it is, you
can do:

burp -t -c /etc/burp/burp-server.conf | grep librsync

It is override-able per client, so you might also want to try:

burp -t -c /etc/burp/burp-server.conf -C <client> | grep librsync


If it is turned on (set to 1), you might want to try turning it off (set
to 0). Sometimes, the generation of librsync signatures and diffs can be
slow, which is possibly related to your network disconnecting.

To set to 0, put 'librsync = 0' in the server side configuration,
either globally in burp-server.conf, or /etc/burp/clientconfdir/<client>.

Re: [Burp-users] Timeout?

[Mark S. <ma...@st...>]

Thanks for that Graham,

On Sun, 2025-11-16 at 23:50 +1000, Graham Keeling wrote:
> That sounds a bit strange.
> Are you able to paste these lines here?

>From "unchanged"

t0028t/etc/NetworkManager/NetworkManager.conf
r003FPwA BhOUH IGk B A A A jX BAA I BpFgGM Boq6eA BpDjuw A A J A A A
f0027/etc/NetworkManager/NetworkManager.conf
x00252263:1d20f45a4ba870f9168cea04a711e40e
t00110000/020B/2C0F.gz
r003FPwA BhOUH IGk B A A A jX BAA I BpFgGM Boq6eA BpDjuw A A J A A A
m0027/etc/NetworkManager/NetworkManager.conf
x002386:ac13a9924203fb4478812ea41bf364c4
t0020t/etc/PackageKit/PackageKit.conf
r003FPwA BBkxP IGk B A A A LC BAA I BpFuZk BoB/XX BpDjus A A J A A A
f001F/etc/PackageKit/PackageKit.conf
x0024706:71da11578968301072133d233e91cd1e
t00110000/020B/2C10.gz
r003FPwA BBkxP IGk B A A A LC BAA I BpFuZk BoB/XX BpDjus A A J A A A
m001F/etc/PackageKit/PackageKit.conf
x002368:8c5af1fef19741200dc23ac012d3108b


"Changed" similarly has conf files tripled.  Other files aren't tripled
in either place, probably unsurprisingly.

> Another question: do you have librsync on or off?

I'm going to have to claim ignorance here.  I'm a programmer, but not a
very system-savvy one.  Where would I find an on/off switch for this? 
This server is running Fedora 43, it's got rsync loaded.

What I do notice is that, whilst the Fedora people have made a Burp
package available, it doesn't get a lot of attention and the last time
they did it was for Fedora 40 (43 is current).  It *is* the 3.1.4
version, but I wonder if that might be an issue.  The client that's
working here is also on that version so perhaps it's fine.  Just
thought I'd mention it.

Also, last night's backup, the one with the extra 47k files, also
failed, this time after 25 minutes (again).

Mark

> 
> _______________________________________________
> Burp-users mailing list
> Bur...@li...
> https://lists.sourceforge.net/lists/listinfo/burp-users

Re: [Burp-users] Timeout?

[Graham K. <gr...@gr...>]

On Sat, Nov 15, 2025 at 10:14:02AM +0000, Mark Stanton wrote:
> The first file in "unchanged" is 
> 
> 	/etc/NetworkManager/NetworkManager.conf
> 
> In fact the first three files are that.  Is that right?

That sounds a bit strange.
Are you able to paste these lines here?

> I have a line in burp.conf of
> 
> 	include_glob = /etc/*/*.conf
> 
> There are other .conf files in "changed" so I'm guessing it's not
> really this glob that's causing the problem (is it?)

Yes, it is possible that the double glob is causing the problem if it's
resulting in the same file ending up in the manifests multiple times.

Another question: do you have librsync on or off?