# Seqera Platform Compute Environment error

**URL:** <https://community.seqera.io/t/seqera-platform-compute-environment-error/1986>\
**Category:** Ask for help\
**Tags:** seqera\
**Created:** [March 19, 2025, 3:43pm UTC](https://community.seqera.io/t/seqera-platform-compute-environment-error/1986 "2025-03-19T15:43:58Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![ramirobarrantes](https://dub1.discourse-cdn.com/flex013/user_avatar/community.seqera.io/ramirobarrantes/32/717_2.png) [@ramirobarrantes](https://community.seqera.io/u/ramirobarrantes)\
**Post date:** [March 19, 2025, 3:43pm UTC](https://community.seqera.io/t/seqera-platform-compute-environment-error/1986/1 "2025-03-19T15:43:58Z")

</div>

Our network was upgraded to RHEL9 and made some changes. When I tried to update the compute environment I get an error:

> Failed to validate HPC scheduler availability - command: [sinfo, --version]; status=1; output:

However, when I try running from the command line it works fine:

```auto
>ssh mbsr@login2.vacc.uvm.edu sinfo --version
slurm 24.05.4

```

Any suggestions for figuring this out?

---

<div class="post-metadata">

**Author:** ![kenibrewer](https://dub1.discourse-cdn.com/flex013/user_avatar/community.seqera.io/kenibrewer/32/963_2.png) [@kenibrewer](https://community.seqera.io/u/kenibrewer)\
**Post date:** [March 23, 2025, 6:47pm UTC](https://community.seqera.io/t/seqera-platform-compute-environment-error/1986/2 "2025-03-23T18:47:07Z")

</div>

Hey Ramiro!

Did they change the networking policies for the HPC? When you log into the HPC do you have to connect to a VPN or be on campus first?

Many/most HPC environments don’t allow ssh connections from public IP address. Usually you have to ask the network admins to whitelist Seqera Cloud’s IP addresses to allow inbound SSH connections or switch to the [Tower Agent credential type](https://docs.seqera.io/platform/25.1/credentials/agent_credentials) instead.

---

<div class="post-metadata">

**Author:** ![kenibrewer](https://dub1.discourse-cdn.com/flex013/user_avatar/community.seqera.io/kenibrewer/32/963_2.png) [@kenibrewer](https://community.seqera.io/u/kenibrewer)\
**Post date:** [March 24, 2025, 5:04pm UTC](https://community.seqera.io/t/seqera-platform-compute-environment-error/1986/3 "2025-03-24T17:04:33Z")

</div>

I found the page in the docs where you can find the IP addresses used by Seqera Cloud:

> **[Firewall configuration | Seqera Docs](https://docs.seqera.io/platform/24.2/enterprise/advanced-topics/firewall-configuration)**
>
> Configure your firewall to allow Seqera Cloud access

---

<div class="post-metadata">

**Author:** ![Crows\_Laughing](https://dub1.discourse-cdn.com/flex013/user_avatar/community.seqera.io/crows_laughing/32/1716_2.png) [@Crows\_Laughing](https://community.seqera.io/u/Crows_Laughing)\
**Post date:** [March 27, 2025, 7:08pm UTC](https://community.seqera.io/t/seqera-platform-compute-environment-error/1986/4 "2025-03-27T19:08:50Z")

</div>

I’m one of Ramiro’s system administrators.

This is not an issue with a firewall. The logs on our machine indicate successful network connection from 18.171.4.252, and the ssh key is correct and being accepted. We see a session being opened, some time elapses, and then the connection is closed from the Seqera end. For whatever reason, Seqera does not seem to be recognizing that the session is open, so it closes the connection after a few minutes.

Please note that using a real ssh client from a remote host terminal window other than Seqera and running sinfo --version works fine. The problem seems to be that Seqera’s connection method is not recognizing that a session has been granted.

Note that we have older machines, and the sinfo command seems to work when Seqera is pointed to those. The new and old machines share a common network home directory.

What Ramiro really needs is a way to get debugging information from the Seqera server to see what it thinks is happening after the session opens. As far as we can tell, everything is right on our end.

---

<div class="post-metadata">

**Author:** ![ramirobarrantes](https://dub1.discourse-cdn.com/flex013/user_avatar/community.seqera.io/ramirobarrantes/32/717_2.png) [@ramirobarrantes](https://community.seqera.io/u/ramirobarrantes)\
**Post date:** [March 28, 2025, 7:01pm UTC](https://community.seqera.io/t/seqera-platform-compute-environment-error/1986/5 "2025-03-28T19:01:15Z")

</div>

I met with the sysadmins at the University and did some troubleshooting. We verified with tcpdump that packets are going between both hosts. Something in your python connection doesn’t seem to be recognizing that a session is open. Note: the change from old cluster to the new cluster is that session startup is now systemd when it was not before. Testing ocurred March 28 14:20 to 14:40 Eastern Time (New York time). Our host name is login4.vacc.uvm.edu and we were using user mbsr. We are happy to send you more login information privately.

---

<div class="post-metadata">

**Author:** ![kenibrewer](https://dub1.discourse-cdn.com/flex013/user_avatar/community.seqera.io/kenibrewer/32/963_2.png) [@kenibrewer](https://community.seqera.io/u/kenibrewer)\
**Post date:** [March 31, 2025, 3:04pm UTC](https://community.seqera.io/t/seqera-platform-compute-environment-error/1986/6 "2025-03-31T15:04:11Z")

</div>

Hi @ramirobarrantes and @Crows_Laughing !

I passed your report onto our engineers who cross-referenced it to our internal logs. We were able to validate that the ssh connection is formed correctly and Seqera’s services recognize that the ssh session is open.

The problem comes during the second step in the connection process when trying to determine if `sinfo` is available. The full command that Seqera Platform runs from within the ssh sessions during this check is `bash --login -ec 'sinfo --version'`.

In your case, the error is likely simply what the message says. Somehow in the bash environment that Seqera Platform gets through SSH, `sinfo` and other slurm commands aren’t added to `$PATH`. Some places to look at to help you troubleshoot are:

- Instead of running `ssh mbsr@login2.vacc.uvm.edu sinfo --version` as a single command, run `sinfo --version` within an already created ssh session.
- Check if your local ssh client has some configuration (e.g some files in `~/.ssh` folder) that may be influencing what’s in `$PATH`.
- Check for differences in the bash profiles of the older and newer machines (unless that is included in “common network home directory”).
- Check to ensure all of the network paths are properly mounted on the newer server nodes.

Hope this helps in your troubleshooting!

---

<div class="post-metadata">

**Author:** ![Crows\_Laughing](https://dub1.discourse-cdn.com/flex013/user_avatar/community.seqera.io/crows_laughing/32/1716_2.png) [@Crows\_Laughing](https://community.seqera.io/u/Crows_Laughing)\
**Post date:** [March 31, 2025, 5:55pm UTC](https://community.seqera.io/t/seqera-platform-compute-environment-error/1986/7 "2025-03-31T17:55:42Z")

</div>

Thanks for suggesting running the shell and the command it is to invoke; that revealed the issue.

Our newer installation runs

```auto
$ bash --version
GNU bash, version 5.1.8(1)-release (x86_64-redhat-linux-gnu)

```

as distributed with Red Hat 9 (and equivalents). The version of bash on the older installation is

```auto
$ bash --version
GNU bash, version 4.2.46(2)-release (x86_64-redhat-linux-gnu)

```

as distributed with Red Hat 7 (and equivalents). The combination of `-ec` flags does not seem to work with bash version 5, as it comes with Red Hat 9.

Using your suggestion, on the older installation we get

```auto
$ bash --login -ec 'sinfo --version'
slurm 23.02.7
$ echo $?
0

```

Whereas on the newer installation, we get

```auto
$ bash --login -ec 'sinfo --version'
$ echo $?
1

```

This can be worked around on our end by setting the `BASH_COMPAT` variable to 4.2 on the command line, as in

```auto
$ BASH_COMPAT=4.2 bash --login -c 'sinfo --version'
slurm 24.05.4

```

Alternately, one can drop the `-e` option from the `bash` command,

```auto
$ bash --login -c 'sinfo --version'
slurm 24.05.4

```

and that also works on the newer installation.

Unfortunately, this seems only to work from the interactive prompt, as neiter adding the command

```auto
export BASH_COMPAT=4.2

```

nor adding

```auto
shopt -s compat42

```

to either the user’s `.bashrc` file or to the `.bash_profile` seem to make the command without the explicit variable declaration on the `bash` command line work.

I haven’t been able to find a way to get a compatibility mode set up that will enable bash 5.1 to Just Work with the `bash --login -ec 'sinfo --version'` command. That `-e` flag seems to be the problem.

We have a pretty generic RH9 installation, so I don’t think we’ve done anything to make this behavior occur.

---

<div class="post-metadata">

**Author:** ![ramirobarrantes](https://dub1.discourse-cdn.com/flex013/user_avatar/community.seqera.io/ramirobarrantes/32/717_2.png) [@ramirobarrantes](https://community.seqera.io/u/ramirobarrantes)\
**Post date:** [March 31, 2025, 7:18pm UTC](https://community.seqera.io/t/seqera-platform-compute-environment-error/1986/8 "2025-03-31T19:18:11Z")

</div>

Hello, actually, this just worked adding the following on our `.bashrc` file:

`export BASH_COMPAT=4.2`

---

<div class="post-metadata">

**Author:** ![ramirobarrantes](https://dub1.discourse-cdn.com/flex013/user_avatar/community.seqera.io/ramirobarrantes/32/717_2.png) [@ramirobarrantes](https://community.seqera.io/u/ramirobarrantes)\
**Post date:** [April 7, 2025, 7:18pm UTC](https://community.seqera.io/t/seqera-platform-compute-environment-error/1986/9 "2025-04-07T19:18:12Z")

</div>

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.