Skip to content

Commit 32936e5

Browse files
authored
Handle non-zero subprocess exits (#5660)
With PR #5634 (which had the goal to remove I/O in event loop for backup operations) the semantics of `remove_folder` changed slightly: Non-zero exits of subprocesses were no longer handled, but lead to a CalledProcessError. Now to restore the semantics of `remove_folder` we should simply log an error. However, this semantic change actually uncovered a potential problem in deployed systems: There are 34 users on beta channel which regularly seem to run `FixupStoreExecuteReset`, and with the semantic change we see those errors in Sentry. An obvious problem could be no storage. But in a quick test that would not execute the repair in first place since the fixup has the job condition `FREE_SPACE` set. So the problem is likely elsewhere. With this change, we log the stderr of find, while still raising the exception. With that we should get more context in Sentry to see what could be the underlying error.
1 parent c35746c commit 32936e5

File tree

1 file changed

+4
-3
lines changed

1 file changed

+4
-3
lines changed

supervisor/utils/__init__.py

Lines changed: 4 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -95,18 +95,19 @@ def remove_folder(
9595
if content_only:
9696
find_args.extend(["-mindepth", "1"])
9797
try:
98-
proc = subprocess.run(
98+
subprocess.run(
9999
["/usr/bin/find", str(folder), "-xdev", *find_args, "-delete"],
100100
stdout=subprocess.DEVNULL,
101101
stderr=subprocess.PIPE,
102102
env=clean_env(),
103103
text=True,
104104
check=True,
105105
)
106-
if proc.returncode != 0:
107-
_LOGGER.error("Can't remove folder %s: %s", folder, proc.stderr.strip())
108106
except OSError as err:
109107
_LOGGER.exception("Can't remove folder %s: %s", folder, err)
108+
except subprocess.CalledProcessError as procerr:
109+
_LOGGER.error("Can't remove folder %s: %s", folder, procerr.stderr.strip())
110+
raise procerr
110111

111112

112113
def remove_folder_with_excludes(

0 commit comments

Comments
 (0)