Slurm template: Signal SIGINT by default to allow R code to catch it gracefully
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 3/5
- Thời gian dự kiến
- 1-2 ngày
- Mức phù hợp với người mới
- 66/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Ít trao đổi
- Công nghệ
- r
- Lĩnh vực
- distributed-systems, infrastructure
Hướng nghiên cứu
Xác định template Slurm và phần xử lý tài nguyên phía sau plan(..., resources = list(signal = ...)); trước tiên hãy kiểm tra cách các giá trị mặc định dành riêng cho scheduler và các giá trị signal được chỉ định rõ ràng hiện đang được truyền qua. Công việc được hoàn tất khi giá trị mặc định của Slurm sử dụng B:INT@60, signal được cung cấp rõ ràng vẫn có hiệu lực, và các test hiện có liên quan được cập nhật hoặc bổ sung nếu dự án có coverage cho template.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
When a job is approaching it's maximum run-time limit, Slurm sends a SIGTERM 30 seconds before sending a SIGKILL (abrupt; not capturable).
R code cannot handle SIGTERM signals, only SIGINT. If Slurm would signal SIGINT instead, we could capture it internally as an interrupt condition, and using tryCatch(..., interrupt = ...), on.exit(), and likes to gracefully exit, e.g. close connections, checkpoint intermediate results, etc.
Slurm allows us to declare what type of signal, and when, to signal when we approach the run-time limit. This can be done by declaring, e.g. --signal=B:INT@60.
Idea
First, should be able to control the signal explicitly via:
plan(..., resources = list(signal = "INT@60"))
already today.
Second, we could update the default to be signal = "INT@60" by adding the following to the template:
## Resources needed
<%
## Default to sending SIGINT 60 seconds before walltime limit
## to allow graceful R-level cleanup/checkpointing
if (is.null(resources[["signal"]])) {
resources[["signal"]] <- "B:INT@60"
}
...
%>
Third, alternative to a Slurm-specific resource name, we might harmonize the signal type and signal grace period with what is used by other job schedulers.
- Ngôn ngữ chính
- R
- Star
- 87
- Fork
- 10
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của futureverse/future.batchtools
-
feature/resources scheduler/lsf
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
futureverse/future.batchtools#105 ·
-
feature/resources scheduler/sge
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 50/100
futureverse/future.batchtools#104 · 1 bình luận ·
-
Add batchtools_hyperqueue()Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 55/100
futureverse/future.batchtools#102 ·
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 15/100
-
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 35/100
Tất cả issue của futureverse/future.batchtools
Issue tương tự
-
Component: R
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 2 ngày
-
bug pixi-build-r
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
prefix-dev/pixi#7229 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
rstudio/reticulate#1933 ·
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 62/100