Re: Filling up /var/spool

hey Joachim,

On 27.05.2024 10:08, Joachim Langenbach via Duplicity-talk wrote:
> Hello together,
>
> we have some backup jobs running on our server. Sometimes a backup jobs fails. And after a certain amount of failes, the /var/spool volume is shown as full. Actually it is not filled really, but the space is occupied by file handles of dead processes. Many of them are duplicity.
>
> This is typically the last report before the volume is full:
>
> Giving up after 5 attempts. OSError: Quota exceeded
> 2024-05-08 05:53:49.765 Task 'BKP' failed with exit code '50'.
> Invalid data - SHA1 hash mismatch for file:
> duplicity-full.20240508T030756Z.vol1.difftar.gpg
> Calculated hash: 0724bb31e26b7fe7975f40b4bfefb5913b5b6fe5
> Manifest hash: ba61cc857e2bbcc4bb9be9b1350589a61562d29c
> 2024-05-08 05:53:57.250 Task 'VERIFY' failed with exit code '21'.

'Quota exceeded' is a pretty forward error message.

1. what are the quotas for that user on that system?
2. can you please post the outputs for
`cat /proc/sys/fs/file-max`
`ulimit -n`
?

also please state your operating system and duplicity version.

> Do you have any idea, how to solve this issue? It is ok, that the backup is failing sometime, but there should be no open file handles from dead processes. That's my first priority :-)

if handles are kept open after duplicity finished or crashed then there should still be processes running keeping them open. you may want to check your system for lingering gpg processes and simply kill them. that is not supposed to happen, but would be the only reason i can imagine that handles are kept.

duplicity running out of file descriptors is usually caused by very long backup chains with lot's of volumes. could you please post the output of `duply status`?

sunny regards ..ede/duply.net

_______________________________________________
Duplicity-talk mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/duplicity-talk