That is why any sensitive data should *always* be encrypted before being stored on any system you do not *fully* control. And *really* sensitive data should not even leave your systems, even encrypted, without a *good* reason.

Could you mitigate the scrapers by rate-limiting by IP address? Eg addresses making more that 10 requests per minute get responses delayed so they only get 10 responses per minute. That would not be too bad for a human, but hurt scrapers trying to train an AI system.

Sites that are obviously training an AI system should be fed AI generated drivel so they end up with an AI system that produces rubbish output.

I've nearly run out of ideas. I don't know much about networking.

Is there any pattern to which systems respond to ping from the laptop. Eg does it work for systems connected wirelessly but not ones with a wired connection? Do their IP addresses have any pattern (eg 192.168.1,* work but 192.168.0.* don't)?

Does the laptop respond to pings from other systems? If so does it respond to all the systems you can ping from?

Here are a few thing to check:

How are the systems connected to your network?
If any systems are connected wirelessly check they are connected to *your* router, not one belonging to a neightbour. That has been known.
If the laptop also has an ethernet port try connecting it to your router with an ethernet cable. Does that change the symptoms?

What are the symptoms of ping not working? Replace target with the name of the system you are trying to reach below (server, laptop, etc):
host target - does this return the servers IP address?
traceroute target - how many hops away is the server?
ping target - what does it say?
ssh -v target - some systems don't respond to ping but will allow a ssh connection. The -v will make ssh show how far it gets.

I hope that gives you some help.

Glad to hear its sorted.

I'm not sure if your analysis is right, but it sounds reasonable.

I spent several years as a UNIX admin before I retired. But the servers my team were looking after didn't have GUIs installed, to save memory. So I know UNIX/Linux from the command line quite well, but I'm not very familiar with GUIs. Still that seems a complimentary skill set to a lot of the others on this forum.

From man chattr:
Only the superuser or a process possessing the CAP_LINUX_IMMUTABLE capability can set or clear this attribute.

And what are the ownership and permissions of the directory? That is what controls which accounts can delete a file.

I am starting to suspect igorzwx is a bot posting AI generated posts. Several of his posts look like an AI system hallucinating a mixture of unrelated text, with similar words but unrelated meaning.

I would have started with ls -li /bin/xdotool /usr/bin/xdotool and checked the inode numbers were different. If two files in the same filesystem have the same inode number they are really the same file, possibly hard linked, possibly one part of one path is a link to part of the other path.

Eg if /bin is a symlink to /usr/bin then everthing in one is really the same file as in the other.

I'd also have moved /bin/xdotool to somewhere else in case it really turned out to be needed. Probably after diff /bin/xdotool /usr/bin/xdotool as well.

Please post output from:
file /usr/bin/apt-mirror

If it's some script, eg perl, then read it and see what line 920 is doing. If you don't know the language then post line 920 and a few lines each side of it.

When it's locked up will ctrl-alt-f1 get you to a text console? (Try this when it's OK to see what to expect, ctrl-alt-f7 to get back to GUI.)

Have you got another system you can use to ssh onto it from? Running top from the ssh session should give you some more info.

Does anything interesting appear in any of the logs?

What is in your /etc/apt/sources.list ? Your first quote contains:

E: Failed to fetch http://deb.debian.org/debian/pool/main/g/guava-libraries/libguava-java_31.1-1_all.deb  Connection timed out [IP: 199.232.18.132 80]

Which suggests you have a mixture of devuan and debian resources. That is a recipe for disaster. You should only have devuan in there. Also check /etc/apt/sources.list.d/ as well.

And I'm not sure where the IP address 199.232.18.132 is supposed to be. Reverse DNS lookup fails but it responds to ping.

Can you make avahi work again by restarting it (if all else fails by rebooting the system)? If so you could try switching off each device in turn until you find the one that causes avahi to fail (hoping there's only one such device). It might take a while though.