Skip to content
This repository has been archived by the owner on Jul 7, 2020. It is now read-only.

do not swallow exceptions for disk checks #131

Closed
wants to merge 1 commit into from

Conversation

cburroughs
Copy link
Contributor

WriteableDiskCheck can fail for a variety of reasons besides the
underlying open or utimensat syscalls failing. For example:
another directory (such as /bin or /lib) can not be read, a
shared library could be missing, a ulimit reached, or a bug in the
check itself. To allow those situations to be debugged we need to
exception.

NOTE: Log is at WARN to preserve 'at least one path must be writeable'
semantics. However, those semantics are nuts and should probably be
changed to 'all paths must be writeable'.

`WriteableDiskCheck` can fail for a variety of reasons besides the
underlying `open` or `utimensat` syscalls failing.  For example:
another directory (such as `/bin` or `/lib`) can not be read, a
shared library could be missing, a ulimit reached, or a bug in the
check itself.  To allow those situations to be debugged we need to
exception.

NOTE: Log is at WARN to preserve 'at least one path must be writeable'
semantics.  However, those semantics are nuts and should probably be
changed to 'all paths must be writeable'.
@tea-dragon
Copy link
Contributor

Are you sure those cases all throw exceptions? I would expect at least a few of them to manifest as non-zero exit values for the Process object. You might be better served by checking the actual exit value and/or the contents of stderr.

@mspiegel
Copy link
Contributor

Can we revisit this? It looks like this pull request is better than the current behavior which is to drop exceptions on the floor.

@tea-dragon
Copy link
Contributor

  • we aren't entirely sure this catches any (not to mention all) cases we care about, and if it doesn't, then it is definitely misleading to future maintainers
  • in the use case where it does the, admittedly terrible, thing of passing if any one check succeeds, then this can cause an arbitrarily high amount of log spam that is presumably completely uninteresting

mspiegel pushed a commit that referenced this pull request Feb 20, 2015
Addresses the issues that were brought up in #131
mspiegel pushed a commit that referenced this pull request Mar 4, 2015
Addresses the issues that were brought up in #131. Add a wrapper class that executes child processes.
Does not attempt to consume from standard output or standard
error. Kills the child process if the child is blocking
on the output streams. This is preferred for our use cases
where the alternative is to create an extra thread to consume
from these streams.
@mspiegel
Copy link
Contributor

mspiegel commented Mar 5, 2015

This has been superseded by #151

@mspiegel mspiegel closed this Mar 5, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants