[
https://issues.apache.org/jira/browse/FLINK-5970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16786546#comment-16786546
]
Chesnay Schepler commented on FLINK-5970:
-----------------------------------------
The \{{TaskManagerRunnerStartupTest}} likely suffers from the same issue.
In fact every test that uses the return value of {{File#setWritable}} have the
same problem.
> Job-/TaskManagerStartupTest may run indefinitely
> ------------------------------------------------
>
> Key: FLINK-5970
> URL: https://issues.apache.org/jira/browse/FLINK-5970
> Project: Flink
> Issue Type: Bug
> Components: Runtime / Coordination, Tests
> Affects Versions: 1.3.0, 1.4.0
> Reporter: Chesnay Schepler
> Assignee: Chesnay Schepler
> Priority: Major
>
> The Job- and TaskManagerStartupTest both contain a test that verifies that
> the JM/TM fails when giving a non-writable directory.
> In case of the TM this directory is used for temporary files, see
> testIODirectoryNotWritable.
> In case of the JM this directory is given to the blobService, see
> testJobManagerStartupFails.
> To that end it is necessary to create a non-writable directory. To verify
> that this is at all possible we first rule out the Windows OS (for which
> File#setWritable has no effect), and check the return value of
> File#setWritable, which according to the documentation returns true if the
> file was in fact marked as non-writable.
> When playing around with the BuddyWorks CI i noticed that these tests did
> neither fail nor succeed; we are able to create a non-writable directory
> (which i verified by checking the actual permissions), but the JM/TM still
> start up fine. As a result the tests just run indefinitely since this case
> wasn't considered.
> I'm still investigating why they don't fail; my current assumption is that in
> this case files simply don't inherit the permissions of the parent directory.
> This means that the checks that the tests make aren't adequate. Instead of
> verifying the permissions on the directory I propose verifying the actual
> failure condition: That we can't create new files in this directory.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
