Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Failed Windows Logcollector tests on 4.8.0 Beta 2 #5034

Closed
Deblintrake09 opened this issue Feb 27, 2024 · 3 comments
Closed

Failed Windows Logcollector tests on 4.8.0 Beta 2 #5034

Deblintrake09 opened this issue Feb 27, 2024 · 3 comments

Comments

@Deblintrake09
Copy link
Contributor

Deblintrake09 commented Feb 27, 2024

Target version Related issue
4.8.0 - Beta 2 wazuh/wazuh#22125

Description

During release testing 4.8.0 Beta 2 IT suite execution, a Logcollector test failed on Windows endpoint due to a folder not being empty and could not be removed. Mey be caused by race condition.

This tests have not been migrated to github actions.

The displayed error in all tests occurred during test teardown:

conftest.py:1330: in create_files_in_folder
    delete_path_recursively(folder_path)
C:\Python311\Lib\site-packages\wazuh_testing\tools\file.py:244: in delete_path_recursively
    shutil.rmtree(path, onerror=on_write_error)
C:\Python311\Lib\shutil.py:759: in rmtree
    return _rmtree_unsafe(path, onerror)
C:\Python311\Lib\shutil.py:626: in _rmtree_unsafe
    onerror(os.rmdir, path, sys.exc_info())
C:\Python311\Lib\shutil.py:624: in _rmtree_unsafe
    os.rmdir(path)
E   OSError: [WinError 145] The directory is not empty: 'c:\\testfolder\\subfolder'
 -----------------------------Captured stdout setup------------------------------ 
The Wazuh service is starting.

The Wazuh service was started successfully.




 -----------------------------Captured stderr setup------------------------------ 
2024-02-26 17:05:22,465 - wazuh_testing - DEBUG - Set local_internal_option to {'windows.debug': '2', 'agent.debug': '2'}
2024-02-26 17:05:22,466 - wazuh_testing - DEBUG - Restarting all daemon

 -------------------------------Captured log setup------------------------------- 
DEBUG    wazuh_testing:conftest.py:694 Set local_internal_option to {'windows.debug': '2', 'agent.debug': '2'}
DEBUG    wazuh_testing:conftest.py:144 Restarting all daemon
 ----------------------------Captured stdout teardown---------------------------- 


The Wazuh service was stopped successfully.

More research is needed.

@Deblintrake09 Deblintrake09 changed the title Failed Windows Syscollector tests on 4.8.0 Beta 2 Failed Windows Logcollector tests on 4.8.0 Beta 2 Feb 27, 2024
@vikman90
Copy link
Member

Might this be related to wazuh/wazuh#21791? If it is, this is a stopper. Otherwise, let's add it to the backlog.

@jotacarma90
Copy link
Member

jotacarma90 commented Feb 27, 2024

Analysis

Not reproduced

After a thorough investigation of this error, I have not been able to reproduce it at any time locally. I have run the entire logcollector test suite multiple times, and on a few occasions I have encountered random and flaky errors in other tests, but no in the test_win_location_wildcards.py test, And no error similar at reported in this issue:
E OSError: [WinError 145] The directory is not empty: 'c:\\testfolder\\subfolder'

image

I rule out that it could be related to the change of issue wazuh/wazuh#21791, as the test seems to be working without any problems.

The random flaky problems encountered seem to be related to disconnections with the manager during testing.
I have relaunched the Windows test pipeline again and it seems to have passed completely without problems:
https://ci.wazuh.info/job/Test_integration/46452/

@vikman90
Copy link
Member

I joined this research. There was concern that the agent, which was monitoring the files, might be blocking some of them.

To investigate, we configured the agent to monitor a file with Logcollector and then attempted to delete it while it was open. There were no issues encountered, leading us to conclude that the agent does not have this bug and that the test may have some other problem.

Proposal

Our proposal is to enhance the test to report which file still exists after the deletion attempt. This could provide a clue to finding the root cause of the issue.

Conclusion

At the moment, this issue is not a release stopper.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Development

No branches or pull requests

3 participants