Bug 1775665
| Summary: | [RFE] ipa-backup might leave a system in offline state when the backup failed | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Thorsten Scherf <tscherf> |
| Component: | ipa | Assignee: | Thomas Woerner <twoerner> |
| Status: | CLOSED WONTFIX | QA Contact: | ipa-qe <ipa-qe> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 8.1 | CC: | fcami, rcritten, tscherf |
| Target Milestone: | rc | Keywords: | FutureFeature |
| Target Release: | 8.0 | Flags: | pm-rhel:
mirror+
|
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-01-30 18:01:59 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1796589 | ||
| Bug Blocks: | |||
|
Description
Thorsten Scherf
2019-11-22 14:30:53 UTC
I think the current behavior is fine because: * not restarting services (e.g. having services down) should alert an IPA administrator that something is wrong (ideally via monitoring) * restarting services (esp. DS) without sufficient disk space might be problematic (ENOSPC possibly leading to DB corruption). The behavior is of course not ideal but at least an administrator would have to take action and understand why the backups have been failing. There is a lot of room for improvement: * it should be doable to compute how much space temporary files for a backup would take, as we know how much each entry would consume * this could be used in turn by both ipa-backup and ipa-healthcheck. Thorsten, do you agree with the above? (In reply to François Cami from comment #1) > I think the current behavior is fine because: > * not restarting services (e.g. having services down) should alert an IPA > administrator that something is wrong (ideally via monitoring) A failed backup should not lead to a complete service down situation. > * restarting services (esp. DS) without sufficient disk space might be > problematic (ENOSPC possibly leading to DB corruption). We are talking about temporary disk space that is required to hold temporary files while the backup is created. These files are usually stored in /tmp (unless TMPDIR is set to some other folder). > The behavior is of course not ideal but at least an administrator would have > to take action and understand why the backups have been failing. > > There is a lot of room for improvement: > * it should be doable to compute how much space temporary files for a backup > would take, as we know how much each entry would consume Yes, we should calculate how much space is needed for the temporary files used by the backup tool. When less space is available the tool should give a warning with the options to a) either free disk space in /tmp or b) set TMPDIR variable to a different directory that has sufficient disk space (only for the time the backup is running). Then the tool should exit. > * this could be used in turn by both ipa-backup and ipa-healthcheck. > > Thorsten, do you agree with the above? See comments above. > These files are usually stored in /tmp Agreed, but there is no check either that /tmp and /var/lib are separate file systems. This is why I argue it is best to leave services off at the time. > Yes, we should calculate how much space is needed for the temporary files used by the backup tool. I think this is where we'll be going as a general enhancement. It will solve the above issue. This was discussed in the FreeIPA triage meeting this week and the consensus is that if ipa-backup fails, IPA services should be left in the stopped state due to the concerns listed in https://bugzilla.redhat.com/show_bug.cgi?id=1775665#c3 . Therefore I am closing this bug as WONTFIX. I have however opened https://bugzilla.redhat.com/show_bug.cgi?id=1796589 to avoid such situations. |