# Cylc 8.6.2 how to grab execution time limit as variable

**URL:** <https://cylc.discourse.group/t/cylc-8-6-2-how-to-grab-execution-time-limit-as-variable/1294>\
**Category:** Cylc Support\
**Created:** [March 6, 2026, 10:48pm UTC](https://cylc.discourse.group/t/cylc-8-6-2-how-to-grab-execution-time-limit-as-variable/1294 "2026-03-06T22:48:49Z")\
**Posts on this page:** 13\
**Page:** 1

<div class="post-metadata">

**Author:** ![hollabigj](https://avatars.discourse-cdn.com/v4/letter/h/76d3ee/32.png) [@hollabigj](https://cylc.discourse.group/u/hollabigj)\
**Post date:** [March 6, 2026, 10:48pm UTC](https://cylc.discourse.group/t/cylc-8-6-2-how-to-grab-execution-time-limit-as-variable/1294/1 "2026-03-06T22:48:49Z")

</div>

execution time limit = 15m

How do we grab that execution time limit and pass on to the other script for conditional check against age and time.

IE ${CYLC\_TIME…}

Thanks.

---

<div class="post-metadata">

**Author:** ![hilary.j.oliver](https://yyz2.discourse-cdn.com/free1/user_avatar/cylc.discourse.group/hilary.j.oliver/32/4_2.png) [@hilary.j.oliver](https://cylc.discourse.group/u/hilary.j.oliver)\
**Post date:** [March 7, 2026, 1:37am UTC](https://cylc.discourse.group/t/cylc-8-6-2-how-to-grab-execution-time-limit-as-variable/1294/2 "2026-03-07T01:37:52Z")

</div>

Pass it to which “other script”? The job script that the limit applies to?

---

<div class="post-metadata">

**Author:** ![hollabigj](https://avatars.discourse-cdn.com/v4/letter/h/76d3ee/32.png) [@hollabigj](https://cylc.discourse.group/u/hollabigj)\
**Post date:** [March 7, 2026, 7:20am UTC](https://cylc.discourse.group/t/cylc-8-6-2-how-to-grab-execution-time-limit-as-variable/1294/3 "2026-03-07T07:20:17Z")

</div>

Shell script. It can be any script but more scope on the shell script aka .sh

need to grab the execution time limit from flow.cylc and need to have it in other script for compare against time.

---

<div class="post-metadata">

**Author:** ![hilary.j.oliver](https://yyz2.discourse-cdn.com/free1/user_avatar/cylc.discourse.group/hilary.j.oliver/32/4_2.png) [@hilary.j.oliver](https://cylc.discourse.group/u/hilary.j.oliver)\
**Post date:** [March 7, 2026, 8:00pm UTC](https://cylc.discourse.group/t/cylc-8-6-2-how-to-grab-execution-time-limit-as-variable/1294/4 "2026-03-07T20:00:58Z")

</div>

You can use the ‘cylc config’ command to extract any config item from the workflow config.

---

<div class="post-metadata">

**Author:** ![wxtim](https://yyz2.discourse-cdn.com/free1/user_avatar/cylc.discourse.group/wxtim/32/151_2.png) [@wxtim](https://cylc.discourse.group/u/wxtim)\
**Post date:** [March 9, 2026, 8:57am UTC](https://cylc.discourse.group/t/cylc-8-6-2-how-to-grab-execution-time-limit-as-variable/1294/5 "2026-03-09T08:57:57Z")

</div>

Example of Hilary’s answer for a case where `taskB` wants the execution time limit for `taskA`

```bash
ETL_taskA=$(cylc config -i '[runtime][taskA]execution time limit' ${CYLC_WORKFLOW_ID})

```

---

<div class="post-metadata">

**Author:** ![TomC](https://yyz2.discourse-cdn.com/free1/user_avatar/cylc.discourse.group/tomc/32/115_2.png) [@TomC](https://cylc.discourse.group/u/TomC)\
**Post date:** [March 13, 2026, 8:13am UTC](https://cylc.discourse.group/t/cylc-8-6-2-how-to-grab-execution-time-limit-as-variable/1294/6 "2026-03-13T08:13:52Z")

</div>

You could also see if your scheduler (pbs, slurm, etc) exposes the requested time limit, extract it from the scheduler metadata, or see if your admins can make it a variable via hooks or grab it from the job script with a grep.

On a related note though, we have done similar, but just got it from the qstat output I think,so it might be nice if cylc did have it as a variable, in units of seconds.

---

<div class="post-metadata">

**Author:** ![MetRonnie](https://yyz2.discourse-cdn.com/free1/user_avatar/cylc.discourse.group/metronnie/32/125_2.png) [@MetRonnie](https://cylc.discourse.group/u/MetRonnie)\
**Post date:** [March 17, 2026, 11:47am UTC](https://cylc.discourse.group/t/cylc-8-6-2-how-to-grab-execution-time-limit-as-variable/1294/7 "2026-03-17T11:47:45Z")

</div>

You can use `isodatetime` to parse an ISO 8601 duration as a number of seconds, e.g.,

```console
$ isodatetime PT1H --as-total S
3600.0

```

---

<div class="post-metadata">

**Author:** ![TomC](https://yyz2.discourse-cdn.com/free1/user_avatar/cylc.discourse.group/tomc/32/115_2.png) [@TomC](https://cylc.discourse.group/u/TomC)\
**Post date:** [March 17, 2026, 8:13pm UTC](https://cylc.discourse.group/t/cylc-8-6-2-how-to-grab-execution-time-limit-as-variable/1294/8 "2026-03-17T20:13:10Z")

</div>

Yes, but then you have the overhead of python startup with lots of libs being loaded for something that cylc already had converted to seconds to put in the job script. If cylc were to expose it, it’s better to expose it in seconds.

---

<div class="post-metadata">

**Author:** ![hilary.j.oliver](https://yyz2.discourse-cdn.com/free1/user_avatar/cylc.discourse.group/hilary.j.oliver/32/4_2.png) [@hilary.j.oliver](https://cylc.discourse.group/u/hilary.j.oliver)\
**Post date:** [March 17, 2026, 11:36pm UTC](https://cylc.discourse.group/t/cylc-8-6-2-how-to-grab-execution-time-limit-as-variable/1294/9 "2026-03-17T23:36:58Z")

</div>

@TomC - by “have it as a variable”, where do you mean exactly?

In the job script that the limit applies to?

I asked that question of @hollabigj above and they said _“It can be any script”_ - in which case it’s not something that Cylc can do.

It already gets written to the job script (that it applies to) as (e.g.) a PBS directive in seconds.

Do you want Cylc to set it as a shell variable in that job script as well? If so, what’s the use case for that?

---

<div class="post-metadata">

**Author:** ![TomC](https://yyz2.discourse-cdn.com/free1/user_avatar/cylc.discourse.group/tomc/32/115_2.png) [@TomC](https://cylc.discourse.group/u/TomC)\
**Post date:** [March 18, 2026, 12:33am UTC](https://cylc.discourse.group/t/cylc-8-6-2-how-to-grab-execution-time-limit-as-variable/1294/10 "2026-03-18T00:33:13Z")

</div>

> [@hilary.j.oliver](#):
>
> I asked that question of @hollabigj above and they said _“It can be any script”_ - in which case it’s not something that Cylc can do.

I read that as they want to, within a shell script, launched via Cylc, know the time requested.

How I perceive the potential workflow of using the number of seconds requested for a job:

1. Script does stuff with a time limit of 10 minutes
2. Perhaps there is 20 minutes of work sometimes, other times 10 seconds
3. To ensure the script stops cleanly and in a good state, not a random abrupt end from a walltime being hit, before new work is undertaken, you check if there is 2 minutes left until you hit walltime
4. If close to walltime, do not proceed with any new work, let existing work finish, save state, continue next time it runs

I’m not saying the above design is ideal or optimal, but if it is a design pattern used (I do know of one system that does this), then having a `CYLC_REQUESTED_EXECUTION_TIME_LIMIT` (or similar) variable defined in the shell script would be useful for this limited use case.

---

<div class="post-metadata">

**Author:** ![hilary.j.oliver](https://yyz2.discourse-cdn.com/free1/user_avatar/cylc.discourse.group/hilary.j.oliver/32/4_2.png) [@hilary.j.oliver](https://cylc.discourse.group/u/hilary.j.oliver)\
**Post date:** [March 18, 2026, 1:02am UTC](https://cylc.discourse.group/t/cylc-8-6-2-how-to-grab-execution-time-limit-as-variable/1294/11 "2026-03-18T01:02:42Z")

</div>

Thanks @TomC - fair enough, I’ve never seen a request for that sort of thing before, but I guess it’s plausible.

---

<div class="post-metadata">

**Author:** ![oliver.sanders](https://yyz2.discourse-cdn.com/free1/user_avatar/cylc.discourse.group/oliver.sanders/32/110_2.png) [@oliver.sanders](https://cylc.discourse.group/u/oliver.sanders)\
**Post date:** [March 19, 2026, 4:39pm UTC](https://cylc.discourse.group/t/cylc-8-6-2-how-to-grab-execution-time-limit-as-variable/1294/12 "2026-03-19T16:39:14Z")

</div>

### To answer the question posed

Here’s two solutions (both of which work right now):

1. **Template The Variable**

2. **Extract It From CGroups**

  

### To answer the use case

> I’ve never seen a request for that sort of thing before, but I guess it’s plausible.

I don’t think we’ve seen a request for this either.

I need to think over it more, I’m not sure if “execution time limit aware” jobs are a pattern or anti-pattern.

We do have a few workflows where the “execution time limit” is calculated (i.e, estimated) in the workflow definition or in tasks (via broadcast). Which solves the problem the other way around, somewhat nicer on the batch system and saves messing around with the job, but you have to configure the calculation yourself. In the extreme case, we have a workflow where task runtime is very hard to predict, they solved this by highballing the ETL, then using an end-of-cycle task which monitors task runtime and reduces the ETL (via broadcasts) over subsequent cycles.

But anyway, here’s an alternative way to approach the problem, tested with background, PBS and Slurm job submissions.

Rather than setting a timer inside of your job, this listens for the XCPU signal and uses it for clean shutdown:

_flow.cylc:_

```ini
[scheduling]
    [[graph]]
        R1 = sleepy

[runtime]
    [[sleepy]]
        script = sleepy
        execution time limit = PT5S

```

_bin/sleepy:_

```python
#!/usr/bin/env python

from time import sleep
import signal

CONTINUE = True

def handle_signal(*args):
    global CONTINUE
    print('Caught XCPU')
    CONTINUE = False

for sig in (signal.SIGINT, signal.SIGTERM, signal.SIGINT, signal.SIGXCPU):
    signal.signal(sig, handle_signal)

def run(job):
    sleep(1)

for job in range(1, 1000):
    if CONTINUE:
        print(f'Run job #{job}')
        run(job)
    else:
        print('Exit cleanly')
        break

```

  

Implemented in Python, but obvs can be done in other languages too. A benefit of this is that it’s the standard approach for clean shutdown and can be abstracted to cover other signals (TERM, INT, etc).

But perhaps more generally, at least in Python, this can be reduced to:

```python
dirty = False
try:
    for _ in range(1, 1000):
        dirty = True
        do_thing():
        dirty = False
finally:
    if dirty:
        tidy_thing()

```

---

<div class="post-metadata">

**Author:** ![hilary.j.oliver](https://yyz2.discourse-cdn.com/free1/user_avatar/cylc.discourse.group/hilary.j.oliver/32/4_2.png) [@hilary.j.oliver](https://cylc.discourse.group/u/hilary.j.oliver)\
**Post date:** [March 19, 2026, 10:14pm UTC](https://cylc.discourse.group/t/cylc-8-6-2-how-to-grab-execution-time-limit-as-variable/1294/13 "2026-03-19T22:14:22Z")

</div>

Thanks @oliver.sanders

The templating approach is so easy that IMO we don’t need to consider adding a new environment variable to all jobs when the vast majority of them will never need it.

And the XCPU signal interception example is very nice. At first glance it may seem more difficult than a shell-scripted timing loop, to many users, but it’s cleaner and really not that difficult.

Maybe we should document both of these, under “Handling variable run-length jobs”…