OCF_HEARTBEAT_NGINX(7)

💅 OCF_HEARTBEAT_NGINX(7) — the ocf_heartbeat_nginx tea 🍵

okay bestie, so this whole page is about OCF_HEARTBEAT_NGINX, and honestly? she's a whole icon in the OCF resource agents lineup. sit down, grab a lil drink, we're learning how to babysit an Nginx instance together 🫶

---

✨ NAME ✨

ocf_heartbeat_nginx — literally just manages an Nginx web/proxy server instance. that's her job. that's her whole personality. nginx resource agent energy 👑

---

🎀 SYNOPSIS 🎀

nginx [start | stop | status | monitor | meta-data | validate-all]

---

🦋 DESCRIPTION 🦋

so this is the resource agent for the Nginx web/proxy server, periodt. quick heads up though — this agent does not monitor POP or IMAP servers, because (and I quote the ancestors here) we genuinely don't know how to determine meaningful status for them. so like, don't come for her 💀 she does not play that game.

the start operation? okay so it ends with a loop in which monitor gets repeatedly called — literally just to double-double-check that the server actually started and that it's operational. so bestie, listen: if the monitor operation doesn't succeed within the start operation timeout, the nginx resource will end with an error status. no cap. the vibe check fails, the resource fails 😭

the default monitor operation will verify that nginx is running. simple, cute, does the job.

the level 10 monitor operation by default will try and fetch the /nginx_status page — which is, and I cannot stress this enough, commented out in sample nginx configurations 🫠 so make sure that the /nginx_status page works, AND that access is restricted to localhost (address 127.0.0.1) plus whatever places _outside the cluster_ you want to monitor the server from. see the status10url and status10regex attributes for more details, bestie, they're right there for you.

the level 20 monitor operation performs a more complex set of tests from a configuration file. fancy energy ✨

the level 30 monitor operation runs an external command to perform an arbitrary monitoring operation. main character behaviour, honestly 🌈

---

💖 SUPPORTED PARAMETERS 💖

okay this is the part where I list literally every single one, because we do not skip. we never skip 🎀

• configfile — the full pathname of the Nginx configuration file. this file is parsed to provide defaults for various other resource agent parameters. (unique, optional, string, no default)
• httpd — the full pathname of the httpd binary (optional). (optional, string, default "/usr/sbin/httpd")
• port — a port number that we can probe for status information using the statusurl. this will default to the port number found in the configuration file, or 80, if none can be found in the configuration file. (optional, integer, no default)
• status10url — the URL to monitor (the nginx server status page by default) when given a level 10 monitor operation. if left unspecified, it will be inferred from the nginx configuration file, or defaulted to /nginx_status.

⚠️ if you set this, make sure that it succeeds *only* from the localhost (127.0.0.1) and no other cluster nodes. otherwise, the cluster software may complain about it being active on multiple nodes. dramatic? yes. true? also yes 💀

(optional, string, no default)

• status10regex — regular expression to match in the output of status10url. case insensitive, iykyk. (optional, string, default "Reading: [0-9]+ Writing: [0-9]+ Waiting: [0-9]+")
• testclient — client to use to query to Nginx for level 10 and level 20 tests. if not specified, the RA will try to find one on the system. currently, wget and curl are supported, with curl being preferred 👑 for example, you can set this parameter to "wget" if you prefer that to curl. (optional, string, no default)
• test20url — URL to test. if it does not start with "http", then it's considered to be relative to the document root address. (optional, string, no default)
• test20regex — regular expression to match in the output of test20url. case insensitive. (optional, string, no default)
• test20conffile — a file which contains a more complex test configuration. could be useful if you have to check more than one web application or in case sensitive info should be passed as arguments (passwords). furthermore, using a config file is the only way to specify certain parameters. please see README.webapps for examples and file description 📄 (optional, string, no default)
• test20name — name of the test within the test configuration file. (optional, string, no default)
• external_monitor30_cmd — command string to run which implements level 30 monitoring. (optional, string, no default)
• options — extra options to apply when starting nginx. (optional, string, no default)

---

🔥 SUPPORTED ACTIONS 🔥

this resource agent supports the following actions (operations) — and yes, monitor shows up four separate times on purpose, she contains multitudes 🧚

• start — starts the resource. suggested minimum timeout: 40s.
• stop — stops the resource. suggested minimum timeout: 60s.
• reload — suggested minimum timeout: 40s.
• status — performs a status check. suggested minimum timeout: 30s.
• monitor — performs a detailed status check. suggested minimum timeout: 30s. suggested interval: 10s.
• monitor — performs a detailed status check. suggested minimum timeout: 30s. suggested interval: 30s.
• monitor — performs a detailed status check. suggested minimum timeout: 45s. suggested interval: 60s.
• monitor — performs a detailed status check. suggested minimum timeout: 60s. suggested interval: 61s.
• meta-data — retrieves resource agent metadata (internal use only). suggested minimum timeout: 5s.
• validate-all — performs a validation of the resource configuration. suggested minimum timeout: 5s.

---

💅 EXAMPLE CRM SHELL 💅

here's an example configuration for a nginx resource using the crm(8) shell — copy it exactly, bestie, every quote matters:

primitive p_nginx ocf:heartbeat:nginx \
  op monitor timeout="30s" depth="0" interval="10s" \
  op monitor timeout="30s" depth="10" interval="30s" \
  op monitor timeout="45s" depth="20" interval="60s" \
  op monitor timeout="60s" depth="30" interval="61s"

---

⭐ EXAMPLE PCS ⭐

and here's the same vibe for a nginx resource using pcs(8) — notice it's OCF_CHECK_LEVEL instead of depth, slay:

pcs resource create p_nginx ocf:heartbeat:nginx \
  op monitor timeout="30s" OCF_CHECK_LEVEL="0" interval="10s" \
  op monitor timeout="30s" OCF_CHECK_LEVEL="10" interval="30s" \
  op monitor timeout="45s" OCF_CHECK_LEVEL="20" interval="60s" \
  op monitor timeout="60s" OCF_CHECK_LEVEL="30" interval="61s"

---

🌸 SEE ALSO 🌸

• http://clusterlabs.org/ — go look, it's giving community 🫶

---

🌈 AUTHOR 🌈

ClusterLabs contributors (see the resource agent source for information about individual authors). iconic collective behaviour, honestly 👑

---

and that's the whole page, bestie!! 🎀 this lil gem is from resource-agents version UNKNOWN, dated 10/01/2026 — so go forth, monitor responsibly, and don't forget to restrict that /nginx_status page 💜✨🦋