-
Notifications
You must be signed in to change notification settings - Fork 0
nodes fail to delete workspace if previous job was aborted #45
Comments
I think I've seen this in the past too, usually this happens on Windows though when a file is in use (Windows will prevent you from deleting a file if it is in use), but that's not usually an issue on Linux. It might occur if files are still being added to the folder while trying to remove it. I think
But if you add a new file or directory to a directory between the first and third steps it might fail. It's possible this occurred because the abort did not kill all of the build processes? Maybe some other service was using the directory? I don't know. Without more information I don't know how else to debug it. |
Closing this until we have a resurgence of the issue or a way to reproduce the problem otherwise. |
We had (potentially) another instance of this failure, this time on MacOS: https://ci.ros2.org/job/nightly_osx_release/865/
|
Another possible instance of this https://ci.ros2.org/job/ci_osx/3705/
Instead of being aborted by a user, the previous job on mini2 died with a java stack trace in the console output https://ci.ros2.org/job/ci_osx/3701/console |
There was another instance on the nightly last night: https://ci.ros2.org/view/nightly/job/nightly_osx_release/889/ |
Instances of this appear to have waned again. I believe the lack of cleanup is related to the connection drop and ssh-agent issues in the sense that a lost connection between the Jenkins instance and agent will lead to a bad state on the agent where the bad state consists of dangling workspace directories and running ssh-agent processes. |
Closing as duplicate of #161. |
http://ci.ros2.org/job/ci_linux/3083/console failed after I aborted a job on the same node http://ci.ros2.org/job/ci_linux/3082/
SSH'ing to the directory showed it had many files. I did not check the permissions before deleting the workspace using
sudo
.The text was updated successfully, but these errors were encountered: