Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Slurm template: Signal SIGINT by default to allow R code to catch it gracefully

オープン
#103 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
3/5
見積もり時間
1〜2日
初心者へのやさしさ
66/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
静か
技術スタック
r
領域
distributed-systems, infrastructure

調査の方向性

Slurm テンプレートと、plan(..., resources = list(signal = ...)) の背後にあるリソース処理を見つけてください。まず、スケジューラ固有のデフォルト値と明示的な signal 値が現在どのように渡されているかを確認します。Slurm のデフォルトが B:INT@60 を使用し、明示的に指定された signal が引き続き有効であり、プロジェクトにテンプレートのカバレッジがある場合は、関連する既存のテストが更新または追加されていれば完了です。

索引モデルが issue の本文から書いたものです。

説明

feature/resources scheduler/slurm

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.

主要言語
R
スター
87
フォーク
10
30日以内にマージされた PR はありません

コントリビューションガイド

コントリビューションガイドを開く

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

futureverse/future.batchtools のほかの issue

futureverse/future.batchtools の issue をすべて見る

似ている issue

R の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。