Could not start the Nginx engine after update 6.2.0

[Webics]

nginx: [alert] Unable to start the Phusion Passenger(R) watchdog because it encountered the following error during startup: Unable to start the Passenger core: it seems to have crashed during startup for an unknown reason, with exit code 1 (-1: Unknown error)

AlmaLinux release 9.8 (Olive Jaguar)
nginx version: nginx/1.26.3
Phusion Passenger(R) 6.2.0

[Webics]

Issue is also on AlmaLinux release 8.10 (Cerulean Leopard)

[CamJN]

I just created a fresh alma 9.8 (Olive Jaguar) container and installed Passenger 6.2.0 and Nginx and it all started ok for me, can you describe your setup a bit more or provide a Dockerfile that reproduces the problem?

[Webics]

@CamJN I have the issue on 12 different vpses. Alma 8 and 9. All have 1 app on nginx and fullstaq Ruby 4.0 (jemalloc) Barebone vps boxes so no dockerfile present.

Is there another easy way I can provide more information?

Downgrade to 6.1.8 solved the issue for now

[CamJN]

Well, ideally the steps to take a fresh alma install to the point where it exhibits the problem. So for example:

sudo dnf install -y dnf-utils
sudo dnf install -y https://dl.fedoraproject.org/pub/epel/epel-release-latest-$(< /etc/redhat-release tr -dc '0-9.'|cut -d \. -f1).noarch.rpm
sudo dnf config-manager --enable epel
sudo dnf clean all && sudo dnf update -y
sudo dnf install -y  curl
sudo curl --fail -sSLo /etc/yum.repos.d/passenger.repo https://oss-binaries.phusionpassenger.com/yum/definitions/el-passenger.repo
sudo dnf module enable -y nginx:$(sudo dnf module list nginx | grep -Ee '^nginx.*[0-9\.]+' | cut -d ' ' -f 2 | sort -V | tail -1)
sudo dnf install -y nginx-mod-http-passenger || { sudo dnf config-manager --enable cr && sudo dnf install -y nginx-mod-http-passenger ; }
# steps to create user for running app
# steps to create example webapp
# steps to configure nginx to serve webapp

[Webics]

I understand your point of view. Because there are multiple production servers i hoped I could send more debug info from those. I will try to create a repreducable scenario.

[Webics]

Found the culprit: SELinux

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that PassengerAgent should be allowed getattr access on the core unix_stream_socket by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'PassengerAgent' --raw | audit2allow -M my-PassengerAgent
# semodule -X 300 -i my-PassengerAgent.pp


Additional Information:
Source Context                system_u:unconfined_r:unconfined_t:s0
Target Context                system_u:object_r:passenger_instance_httpd_socket_
                              t:s0
Target Objects                /run/passenger-
                              instreg/passenger.awAfF6u/agents.s/core [
                              unix_stream_socket ]
Source                        PassengerAgent
Source Path                   /usr/lib64/passenger/support-
                              binaries/PassengerAgent
Port                          <Unknown>
Host                          webics.dev
Source RPM Packages           passenger-6.2.0-1.el9.x86_64
Target RPM Packages           
SELinux Policy RPM            selinux-policy-targeted-38.1.75-2.el9_8.noarch
Local Policy RPM              selinux-policy-targeted-38.1.75-2.el9_8.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Permissive
Host Name                     webics.dev
Platform                      Linux webics.dev 5.14.0-687.20.1.el9_8.x86_64 #1
                              SMP PREEMPT_DYNAMIC Tue Jun 30 06:22:49 EDT 2026
                              x86_64 x86_64
Alert Count                   3
First Seen                    2026-08-19 14:52:46 CEST
Last Seen                     2026-08-19 22:41:41 CEST
Local ID                      956fc70e-b394-47a3-8216-eda1666e513a

Raw Audit Messages
type=AVC msg=audit(1787172101.596:20622): avc:  denied  { getattr } for  pid=2281990 comm="PassengerAgent" path="/run/passenger-instreg/passenger.awAfF6u/agents.s/core" scontext=system_u:unconfined_r:unconfined_t:s0 tcontext=system_u:object_r:passenger_instance_httpd_socket_t:s0 tclass=unix_stream_socket permissive=1


type=SYSCALL msg=audit(1787172101.596:20622): arch=x86_64 syscall=getsockname success=yes exit=0 a0=e a1=7ffc2441a430 a2=7ffc2441a40c a3=7fd0a2408270 items=0 ppid=2281986 pid=2281990 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm=PassengerAgent exe=/usr/lib64/passenger/support-binaries/PassengerAgent subj=system_u:unconfined_r:unconfined_t:s0 key=(null)

Hash: PassengerAgent,unconfined_t,passenger_instance_httpd_socket_t,unix_stream_socket,getattr

[matthewjschultz]

Same problem here on Rocky 10.2 with passenger-6.2.0-1.el10 (nginx 1.26.3 from AppStream, SELinux enforcing). Spent this morning digging into it. It's the SELinux policy in the 6.2.0 rpm.

The core dies on its first socket syscall. From /var/log/nginx/passenger.log:

[ C ... age/Cor/CoreMain.cpp:1311 ]: ERROR: Unable to autodetect socket type (getsockname() failed): Permission denied (errno=13)

with this AVC:

type=AVC msg=audit(...): avc:  denied  { getattr } for  pid=... comm="PassengerAgent"
  path="/run/passenger-instreg/passenger.XXXX/agents.s/core"
  scontext=system_u:unconfined_r:unconfined_t:s0
  tcontext=system_u:object_r:passenger_instance_httpd_socket_t:s0
  tclass=unix_stream_socket permissive=0

The policy labels the core's socket passenger_instance_httpd_socket_t, but the core runs as unconfined_t, which is what the policy itself sets up:

$ sesearch -T -s httpd_t -t passenger_exec_t
type_transition httpd_t passenger_exec_t:process unconfined_t;

(there's no passenger_t or other confined domain, seinfo -t passenger_t comes back empty). So the 6.2.0 .te introduces the socket type without letting unconfined_t at it, and the core can't getsockname() its own socket.

Some things I checked/confirmed:

• PassengerAgent is labeled passenger_exec_t correctly, and restorecon on /run/passenger-instreg changes nothing. The labels are already what 6.2.0 wants.
• It's not specific to the nginx module. I also run Passenger standalone (builtin engine) under systemd, and 6.2.0 dies there with the identical AVC.
• In nginx-integrated mode the visible symptom is weird: nginx starts fine, passenger_enabled becomes a no-op, and nginx serves the app's public/ as a bare directory, so you get 403 "directory index forbidden" on every dynamic route while static vhosts keep working. That's how it looked before I found the AVC.
• dnf downgrade to 6.1.8-1.el10 fixes it instantly, re-upgrading reproduces it every time. I'm versionlocked on 6.1.8 for now.

The setroubleshoot output above shows the same denial on el9, so it's the shipped policy on both el9 and el10. One note on reading that trace: it shows success=yes because that box is in permissive mode (permissive=1). Enforcing gets EACCES and the crash from the original report.

Also, careful with the audit2allow module setroubleshoot suggests. It works, but since there's no passenger domain to scope it to, it grants the access to all of unconfined_t, and you have to remember to remove it later. Downgrade + versionlock is the cleaner hold until a fixed build ships.

Guessing the fix is an allow rule for unconfined_t on passenger_instance_httpd_socket_t:unix_stream_socket in the .te (or giving the type whatever attribute unconfined's blanket rules match). Can test a scratch build if useful.

[CamJN]

Thanks so much folks, I'll work on making a fix for this and getting a 6.2.1 out.

[CamJN]

I've made a beta package you can test out, I've already tried it myself in a vm with SELinux set to enforce, but I'd love some more confirmation:

sudo dnf install -y dnf-utils
sudo dnf install -y "https://dl.fedoraproject.org/pub/epel/epel-release-latest-$(rpm -E %rhel).noarch.rpm"
sudo dnf config-manager --enable epel
sudo dnf clean all
sudo dnf update -y
sudo dnf config-manager --add-repo https://oss-binaries.phusionpassenger.com/yum/definitions/el-passenger-testing.repo
sudo dnf install -y nginx-mod-http-passenger

Probably don't install that into production, it hasn't been through our full test suite, I just ran it myself.

[iMHLv2]

I ran into the issue on RHEL 8.10:

# cat /etc/os-release 
NAME="Red Hat Enterprise Linux"
VERSION="8.10 (Ootpa)"
ID="rhel"
ID_LIKE="fedora"
VERSION_ID="8.10"
PLATFORM_ID="platform:el8"
PRETTY_NAME="Red Hat Enterprise Linux 8.10 (Ootpa)"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:redhat:enterprise_linux:8::baseos"
HOME_URL="https://www.redhat.com/"
DOCUMENTATION_URL="https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8"
BUG_REPORT_URL="https://issues.redhat.com/"

REDHAT_BUGZILLA_PRODUCT="Red Hat Enterprise Linux 8"
REDHAT_BUGZILLA_PRODUCT_VERSION=8.10
REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux"
REDHAT_SUPPORT_PRODUCT_VERSION="8.10"

SELinux is enforcing:

# getenforce
Enforcing

The sequence of commands above that installed 6.2.1 from el-passenger-testing.repo seemed to resolve it.

Aside from RHEL 8.10, I also ran into the issue on the following versions:

rhel-10
rhel-8.6
rhel-8.8
rhel-9

My test installs of the following versions also failed, but it might not be for the same reason (perhaps nginx 1.24 vs 1.26 issue) - I need to look closer tomorrow.

centos-10
centos-9
oracle-10
oracle-8
oracle-9

[Webics]

Unfortunately, I can't help with testing in our production environments. Has there been any progress? Has the release been scheduled yet?

[amcfarre-iu]

We ran into this bug on several RHEL9 servers and the 6.2.1 patch from the el-passenger-testing repo resolved the issue. We'd love to see this released into the main repository.