`cpus` trace value does not correspond to used logical cores of the task

[JosuaCarl]

Bug report

• Relates to %cpu / cpus > 100% #6710
• Relates to Nextflow CPU limit does not take effect #5921

Expected behavior and actual behavior

The execution trace should report the logical CPUs the process ran on, but does only the number it should have run on from the config, which is often wrong.

Steps to reproduce the problem

1. Define a config with process.resourceLimits = [cpus: 1]
2. Execute nextflow run demo -r 1.0.2 -profile test,docker -c test.config --outdir out
3. Most of the time some task has a %cpu > 100 which should not be, because cpus is at 1

Program output

	task_id	native_id	name	status	%cpu	cpus	memory
	3	3888223	NFCORE_DEMO:DEMO:SEQTK_TRIM (SAMPLE2_PE)	COMPLETED	91.1%	1	4 GB
	2	3888220	NFCORE_DEMO:DEMO:SEQTK_TRIM (SAMPLE1_PE)	COMPLETED	86.0%	1	4 GB
	4	3889134	NFCORE_DEMO:DEMO:FASTQC (SAMPLE2_PE)	COMPLETED	76.3%	1	4 GB
	1	3888837	NFCORE_DEMO:DEMO:FASTQC (SAMPLE1_PE)	COMPLETED	82.2%	1	4 GB
	6	3890070	NFCORE_DEMO:DEMO:SEQTK_TRIM (SAMPLE3_SE)	COMPLETED	85.4%	1	4 GB
>	5	3890405	NFCORE_DEMO:DEMO:FASTQC (SAMPLE3_SE)	COMPLETED	117.0%	1	4 GB
	7	3891275	NFCORE_DEMO:DEMO:MULTIQC	COMPLETED	44.3%	1	4 GB

Environment

• Nextflow version: [25.10.2]
• Operating system: Linux & MacOS

Additional context

When limiting the cpus via taskset -c <CPU_LIST> nextflow run ..., everything seems to be in order:

task_id	native_id	name	status	%cpu	cpus	memory
2	3329972	NFCORE_DEMO:DEMO:SEQTK_TRIM (SAMPLE2_PE)	COMPLETED	81.7%	1	4 GB
1	3330576	NFCORE_DEMO:DEMO:SEQTK_TRIM (SAMPLE1_PE)	COMPLETED	92.4%	1	4 GB
3	3331266	NFCORE_DEMO:DEMO:SEQTK_TRIM (SAMPLE3_SE)	COMPLETED	90.0%	1	4 GB
4	3331898	NFCORE_DEMO:DEMO:FASTQC (SAMPLE1_PE)	COMPLETED	71.5%	1	4 GB
5	3332979	NFCORE_DEMO:DEMO:FASTQC (SAMPLE2_PE)	COMPLETED	73.9%	1	4 GB
6	3333940	NFCORE_DEMO:DEMO:FASTQC (SAMPLE3_SE)	COMPLETED	77.1%	1	4 GB
7	3334923	NFCORE_DEMO:DEMO:MULTIQC	COMPLETED	38.3%	1	4 GB

[JosuaCarl]

This seems to be dependent on the Executor. For SLURM the -c option can request whole physical cores, rather than logical ones to which the task then has access to. Similarly, rather than using the --cpus option in Docker, --cpu-shares is used, which is less exact and more flexible. The problem is not this strategy, but that Nextflow just seems to take the cpus config value for granted, despite it not corresponding to the number of actually used logical cores.

[JosuaCarl]

Extracting the CPUs that the process is allowed to use: $(cat "/proc/$task/status" | grep Cpus_allowed_list) could be used to generate a notation of CPUs with X-Y or X,Y,Z syntax listing all logical cores that would be available to the process to expand upon.