LSF broken for runtimes given in HH:MM:SS format
まだ誰も着手していません。
評価
- 難易度
- 3/5
- 見積もり時間
- 1〜2日
- 初心者へのやさしさ
- 65/100
- issue の種類
- バグ
- 明瞭さ
- おおむね明確
- 活発さ
- 静か
- 技術スタック
- hpc, python
調査の方向性
LSFCluster のエントリポイントから開始し、その walltime 値が生成されたジョブスクリプトにどのように渡されるかを確認してください。受け付けられる実行時間の形式を、リンク先の LSF ドキュメントおよび示されている 01:00:00 と無効な値の例と比較してください。有効な入力が適切に処理され、無効な入力が明確で対応可能な結果を生成すれば完了です。
索引モデルが issue の本文から書いたものです。
説明
I ran into a really strange issue all of a sudden which took me quite a while to figure out.
Turns out, I had changed from using a walltime="01:00" to a walltime of walltime="01:00:00". This is unexpected because SLURM supports the HH:MM:SS format and some of the documentation presents walltimes in this format.
Currently the walltime seems to be passed down directly to the generated jobscript.
Example
cluster = LSFCluster(
queue="hpc",
cores=4,
memory="8GB",
walltime="01:00:00",
)
client = Client(
cluster,
)
Produces:
2026-07-28 16:09:26,984 - dask_jobqueue.lsf - DEBUG - Job script:
#!/usr/bin/env bash
#BSUB -J dask-worker
#BSUB -q hpc
#BSUB -n 4
#BSUB -R "span[hosts=1]"
#BSUB -M 8000
#BSUB -W 01:00:00
Indeed putting any string in there just gets directly interpolated into the jobscript (tested with 01:abc:00).
Unfortunately misconfiguration gives a very misleading error trace:
2026-07-28 16:17:22,553 - dask_jobqueue.core - DEBUG - Executing the following command to command line
bsub< /tmp/tmpbydzjudm.sh 2> /dev/null
2026-07-28 16:17:22,565 - tornado.application - ERROR - Exception in callback functools.partial(<bound method IOLoop._discard_future_result of <tornado.platform.asyncio.AsyncIOMainLoop object at 0x7f5e03c7afd0>>, <Task finished name='Task-98' coro=<SpecCluster._correct_state_internal() done, defined at /zhome/1a/a/219376/Code/qim-naturarv3d-compression/.pixi/envs/default/lib/python3.14/site-packages/distributed/deploy/spec.py:352> exception=RuntimeError('Command exited with non-zero exit code.\nExit code: 255\nCommand:\nbsub< /tmp/tmpbydzjudm.sh 2> /dev/null\nstdout:\n\nstderr:\n\n')>)
Traceback (most recent call last):
File "/zhome/1a/a/219376/Code/qim-naturarv3d-compression/.pixi/envs/default/lib/python3.14/site-packages/tornado/ioloop.py", line 758, in _run_callback
ret = callback()
File "/zhome/1a/a/219376/Code/qim-naturarv3d-compression/.pixi/envs/default/lib/python3.14/site-packages/tornado/ioloop.py", line 782, in _discard_future_result
future.result()
~~~~~~~~~~~~~^^
File "/zhome/1a/a/219376/Code/qim-naturarv3d-compression/.pixi/envs/default/lib/python3.14/site-packages/distributed/deploy/spec.py", line 396, in _correct_state_internal
await asyncio.gather(*worker_futs)
File "/zhome/1a/a/219376/Code/qim-naturarv3d-compression/.pixi/envs/default/lib/python3.14/asyncio/tasks.py", line 723, in _wrap_awaitable
return await awaitable
^^^^^^^^^^^^^^^
File "/zhome/1a/a/219376/Code/qim-naturarv3d-compression/.pixi/envs/default/lib/python3.14/site-packages/distributed/deploy/spec.py", line 74, in _
await self.start()
File "/zhome/1a/a/219376/Code/qim-naturarv3d-compression/.pixi/envs/default/lib/python3.14/site-packages/dask_jobqueue/core.py", line 426, in start
out = await self._submit_job(fn)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/zhome/1a/a/219376/Code/qim-naturarv3d-compression/.pixi/envs/default/lib/python3.14/site-packages/dask_jobqueue/lsf.py", line 111, in _submit_job
return await self._call(piped_cmd, shell=True)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/zhome/1a/a/219376/Code/qim-naturarv3d-compression/.pixi/envs/default/lib/python3.14/site-packages/dask_jobqueue/core.py", line 514, in _call
raise RuntimeError(
...<5 lines>...
)
RuntimeError: Command exited with non-zero exit code.
Exit code: 255
Command:
bsub< /tmp/tmpbydzjudm.sh 2> /dev/null
stdout:
stderr:
Proposed solution
I think it would be nice if the runtime as parsed as a timedelta and then rendered into either HH:MM or just minutes for the LSFCluster specifically. Alternatively, just checking whether the format is HH:MM:SS for LSFCluster and raising an error that clearly explains this footgun would be a good solution as well.
If there is appetite and one of the solutions above is preferred, I would be happy to submit a PR for it.
Relevant LSF documentation: https://www.ibm.com/docs/en/spectrum-lsf/10.1.0?topic=o-w-1
- 主要言語
- Python
- スター
- 256
- フォーク
- 148
- PR マージ指標
- 30日以内にマージされた PR はありません
環境構築
- Dockerfile・Docker Compose ファイルなし
- プルリクエストのテンプレートなし
- コントリビューションガイドを読む
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
dask/dask-jobqueue のほかの issue
-
難易度 4/5 3〜5日 初心者へのやさしさ 35/100
dask/dask-jobqueue#701 ·
-
難易度 3/5 1〜2日 初心者へのやさしさ 45/100
dask/dask-jobqueue#699 · コメント 2 件 ·
-
bug
難易度 3/5 1〜2日 初心者へのやさしさ 38/100
dask/dask-jobqueue#692 · コメント 1 件 ·
-
bug
難易度 4/5 3〜5日 初心者へのやさしさ 35/100
dask/dask-jobqueue#691 · コメント 7 件 ·
-
難易度 2/5 半日 初心者へのやさしさ 45/100
dask/dask-jobqueue#686 · コメント 3 件 ·
dask/dask-jobqueue の issue をすべて見る
似ている issue
-
bug good first issue
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
yunaremaia/proto-drift#22 ·
-
bug good first issue
難易度 2/5 1〜3時間 初心者へのやさしさ 82/100
yunaremaia/memwatch#96 ·
-
bug good first issue
難易度 1/5 1時間未満 初心者へのやさしさ 91/100
yunaremaia/ci-gate-watch#34 ·
-
bug good first issue
難易度 2/5 1〜3時間 初心者へのやさしさ 85/100
yunaremaia/agent-capability-attestation#64 ·
メンテナーはふだん 1 日以内に返信
-
bug good first issue
難易度 1/5 1時間未満 初心者へのやさしさ 86/100
yunaremaia/agent-call-graph#43 ·
メンテナーはふだん 1 日以内に返信