SAM_OVERVIEW(3)

✨ SAM_OVERVIEW(3) ✨

okay bestie, welcome to the glow-up guide for sam_overview — the Overview of the Simple Availability Manager. this is a (3) manpage, she's a library girlie, and she's about to explain how to keep your processes alive and thriving 💖

---

🌸 OVERVIEW 🌸

the SAM library hands you a tool to check the health of an application. her whole thing, her main character purpose, is restarting a local process when it fails to respond to a healthcheck request inside a configured time interval. that's it. that's the job. 💅

during sam_initialize(3), a duplicate copy of the process gets created using the fork(3) system call. this duplicate copy is lowkey carrying all the logic for running the SAM server. and the SAM server? she's the one requesting healthchecks from the active process, and she's also the one controlling the lifecycle of the active process when it fails. if the active process doesn't respond to the healthcheck request the SAM server sent, it gets a user configurable signal (default SIGTERM) telling it to shut down the application. then, after a configured time interval, the process gets forcibly killed by being sent a SIGKILL signal. no cap. once the active process terminates, the SAM server creates a brand new active process. rebirth era ✨

the Simple Availability Manager is meant to be used in conjunction with the cpg service. used together, you can restart a cpg process that fails healthchecking during operation. power couple behavior 🫶

the main features of SAM include:

• a configurable recovery policy.
• a configurable time interval for health check operations.
• a notification via signal before recovery action is taken.
• a mechanism to indicate to the application the number of times an active process has been created by the SAM server.
• both application driven health checking and event driven health checking.

---

🎀 Initializing SAM 🎀

the SAM library is initialized by sam_initialize(3). sam_initalize(3) may only be called once per process. calling it more than once has undefined results and is not recommended or tested. so like... don't. 🙈

---

💜 Setting warning callback 💜

a user configurable signal (default SIGTERM) is sent to the application when a recovery action is planned. your application can use the signal(3) system call to monitor for this signal. 👀

there are no special constraints on what SAM apis may be called in a warning callback. after time_interval expires, a SIGKILL signal is sent to the active process to force its termination. it's giving final boss energy fr fr 💀

---

🦋 Registering the active process 🦋

the active process is registered with SAM by calling sam_register(3). this function should only be called one time in a process. after a recovery action is taken, the new active process will begin execution at the next line of code in a user process after sam_register(3). iconic behavior, honestly 👑

---

🌈 Enabling event driven healthchecking 🌈

two types of healthchecking are available to you, bestie. the first model is one where the user application healthchecks during its normal operation. it is never requested to healthcheck, and if the active process doesn't respond within the time interval, the process will be restarted.

a more useful mechanism for healthchecking is event driven healthchecking. because this model is directed by the SAM server, it isn't necessary to guess or add timers to the active process to signal a healthcheck operation is successful. slay. to use event driven healthchecking, the sam_hc_callback_register(3) function should be executed. ✨

---

⭐ Quorum integration ⭐

SAM has special policies (SAM_RECOVERY_POLICY_QUIT and SAM_RECOVERY_POLICY_RESTART) for integration with the quorum service. these policies change SAM behaviour in two aspects:

• call of sam_start(3) blocks until corosync becomes quorate
• user selected recovery action is taken immediately after loss of quorum.

---

🍓 Storing user data 🍓

sometimes there is need to store some data, which survives between instances. one can in such case use files, databases, ... or the much simpler in memory solution presented by sam_data_store(3), sam_data_restore(3) and sam_data_getsize(3) functions. memory storage but make it cute 💖

---

🧚 Confdb integration 🧚

SAM has a policy flag used for confdb system integration (SAM_RECOVERY_POLICY_CONFDB). if a process is registered with this flag, a new confdb object PROCESS_NAME:PID is created with the following keys:

• recovery — will be quit or restart depending on policy
• poll_period — period of health checking in milliseconds
• last_updated — Timestamp (in nanoseconds) of the last health check.
• state — state of process (can be one of registered, started, failed, waiting for quorum)

object is automatically deleted if process exits with stopped health checking.

confdb integration with corosync watchdog can be used in implicit and explicit way.

the implicit way is achieved by setting recovery policy to QUIT and letting the process exit with started health checking. if this happened, the object is not deleted and corosync watchdog will take the required action.

the explicit way is useful for situations when a developer can deal with some non-fatal fall of the application. this mode is achieved by setting policy to RESTART and using SAM the same as without Confdb integration. if a real fail is needed (like too many restarts at all, per/sec, ...), it's possible to use sam_mark_failed(3) and let corosync watchdog take the required action. 😤

---

💀 BUGS 💀

(nothing here bestie. the bug section is a ghost town. she said no comment. 🙈)

---

💅 SEE ALSO 💅

• sam_initialize(3)
• sam_data_getsize(3)
• sam_data_restore(3)
• sam_data_store(3)
• sam_finalize(3)
• sam_mark_failed(3)
• sam_start(3)
• sam_stop(3)
• sam_register(3)
• sam_warn_signal_set(3)
• sam_hc_send(3)
• sam_hc_callback_register(3)

---

and that's the whole vibe check, bestie!! this little love letter comes to you from the corosync Man Page, dated 21/05/2010, and it lives forever under the name SAM_OVERVIEW(3) 🌸✨ go keep those processes alive, you absolute icon 💖