Bug 42657 - replication.py completely fills /var with failed move_to pickle files
replication.py completely fills /var with failed move_to pickle files
Status: NEW
Product: UCS
Classification: Unclassified
Component: LDAP
UCS 4.4
Other Linux
: P5 normal (vote)
: ---
Assigned To: UCS maintainers
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2016-10-11 17:55 CEST by Ingo Sieverdingbeck
Modified: 2021-02-05 17:49 CET (History)
2 users (show)

See Also:
What kind of report is it?: Bug Report
What type of bug is this?: 2: Improvement: Would be a product improvement
Who will be affected by this bug?: 5: Will affect all installed domains
How will those affected feel about the bug?: 2: A Pain – users won’t like this once they notice it
User Pain: 0.114
Enterprise Customer affected?: Yes
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:
hahn: Patch_Available+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ingo Sieverdingbeck univentionstaff 2016-10-11 17:55:49 CEST
If a move_to operation could not be processed correctly the listener and the replication module place files in /var/lib/univention-directory-replication and /var/univention-backup/replication and might fill up the complete disc, either by space or by inode. After the disc has been filled completely the listener continues to process new notifier ids buts fails at creating the backup files.

I also noticed that /var/lib/univention-directory-replication seems to be never cleaned up by the listener.

It would avoid manual intervention and filled filesystems, if the backup creation is configurable and the files in /var/lib/univention-directory-replication are removed after a certain time, e.g. based on processed notifier ids since creation.
Comment 1 Stefan Gohmann univentionstaff 2017-06-16 20:41:06 CEST
This issue has been filed against UCS 3. UCS 3 is out of the normal maintenance and many UCS components have vastly changed in UCS 4.

If this issue is still valid, please change the version to a newer UCS version otherwise this issue will be automatically closed in the next weeks.
Comment 2 Philipp Hahn univentionstaff 2020-04-21 15:03:12 CEST
With Bug #34355 fixed with git:07d8c9a42eb7c25234387c611a164337c60f3dce since release-3.2-2~116 UDL guarantees to always perform the two parts of a rename/move transaction in sequence. Therefor it is sufficient to keep the state in memory and the code to persist it to disk can (and should) be removed completely.

Patch in git:phahn/replication