PMDADAEMON(3)

💖 PMDADAEMON 💖

okay bestie, welcome to pmdaDaemon from section 3 of the library functions manual — it's giving "let's make your PMDA a real daemon" and honestly? iconic.

---

✨ NAME ✨

pmdaDaemon — initialize the PMDA to run as a daemon 🧚

---

🌸 C SYNOPSIS 🌸

#include <pcp/pmapi.h>
#include <pcp/pmda.h>

void pmdaDaemon(pmdaInterface *dispatch, int interface,
                const char *name, int domain, const char *logfile,
                const char *helptext);

cc ... -lpcp_pmda -lpcp

---

💅 DESCRIPTION 💅

so pmdaDaemon sets up your pmdaInterface structure to use the interface extensions, assuming your PMDA(3) is gonna be running as a daemon. no cap, that's the whole vibe. 🫶

Here's what the pmdaInterface structure gets initialized with:

• name — the name of the agent. literally just its name, periodt.
• domain — the default domain number of the agent, which uniquely identifies this PMDA from other running PMDAs. lowkey important. it may get changed later by the command line option -d (go peek at pmdaGetOpt(3)).
• logfile — the default path to the log file. this may be replaced by the -l command line option if you're using pmdaGetOpt. heads up bestie: logfile gets copied with strdup(3), so the storage associated with logfile may be released after the call to pmdaDaemon. you don't gotta hold onto it. 💀
• helptext — the default path to the help text (see pmdaText(3)). this may be replaced by the -h command line option if you're using pmdaGetOpt(3). if no help text is installed, or you're not using pmdaText(3), then set this to NULL. otherwise helptext gets copied with strdup(3), so the storage associated with helptext may be released after the call to pmdaDaemon. same energy as logfile, fr fr. ✨

The callbacks get initialized to pmdaProfile(3), pmdaFetch(3), pmdaDesc(3), pmdaText(3), pmdaInstance(3) and pmdaStore(3). yes, all six. main character callback energy. 👑

---

🚨 CAVEAT 🚨

The PMDA must be using PMDA_INTERFACE_2 or later. no earlier versions, bestie, that's the rule. 🙈

Once pmdaDaemon has been called, it is expected that the pmdaInterface structure pointed to by dispatch will remain accessible to the routines in libpcp_pmda. that means not reclaimed off the stack, not freed or otherwise released, etc. like... do not touch it. it lives there now. 🌈

If the caller needs to move or relocate the pmdaInterface structure for any reason, then after the move pmdaInterfaceMoved(3) must be called to re-establish the internal integrity of the pmdaInterface structure at the new location — and it has to happen before any other routine in libpcp_pmda is called. so: move first, then pmdaInterfaceMoved(3), then literally anything else. got it? good. 🎀

---

🔥 DIAGNOSTICS 🔥

• Unable to allocate memory for pmdaExt structure — In addition, the dispatch->status field is set to a value less than zero. not great, not terrible, but mostly not great. 😭
• PMDA interface version interface not supported — The interface version is not supported by pmdaDaemon. that version said "not today" and honestly we respect it. 💀

---

👑 SEE ALSO 👑

PMAPI(3), PMDA(3), pmdaDSO(3), pmdaGetOpt(3), pmdaInterfaceMoved(3) and pmdaText(3). go read them, they're all slay. 🦋

---

and that's the whole page bestie!! this one came from Performance Co-Pilot (PCP), section 3 of the library functions manual — pmdaDaemon(3), mwah. 💜 stay daemon-y, keep your pmdaInterface on the stack, and never free what you didn't malloc. bye pookie!! 🎀✨💖