KTRACE(2)

✨ KTRACE(2) ✨

okay bestie, welcome to the ktrace manual — that's the process tracing system call from the System Calls Manual. yes we're in the big leagues now. it lives in the Standard C Library (libc, -lc), so you're not even gonna have to link anything extra. slay. 💅

---

🌸 SYNOPSIS 🌸

like, here's the vibe, literally copy-paste it:

#include <sys/param.h>
#include <sys/time.h>
#include <sys/uio.h>
#include <sys/ktrace.h>

int
ktrace(const char *tracefile, int ops, int trpoints, int pid);

four arguments. that's it. don't be scared. 🫶

---

🦋 DESCRIPTION 🦋

so the ktrace() system call enables or disables tracing of one or more processes. and the rule is: users may only trace their own processes. no snooping on other people's business, periodt. and only the superuser can trace setuid or setgid programs, because obviously. 🔥

The tracefile argument gives the pathname of the file to be used for tracing. The file must exist and be a regular file writable by the calling process. All trace records are always appended to the file, so the file must be truncated to zero length to discard previous trace data. If tracing points are being disabled (see KTROP_CLEAR below), tracefile may be NULL.

⚠️ note the append thing bestie — it never rewrites, it just keeps piling on. if you want a fresh file you gotta truncate it to zero length yourself. no cap.

The ops argument specifies the requested ktrace operation. The defined operations are:

• KTROP_SET — enable trace points specified in trpoints.
• KTROP_CLEAR — disable trace points specified in trpoints.
• KTROP_CLEARFILE — stop all tracing. like, all of it. bye. 👋
• KTRFLAG_DESCEND — the tracing change should apply to the specified process and all its current children. it's giving generational. 👑

The trpoints argument specifies the trace points of interest. The defined trace points are:

• KTRFAC_SYSCALL — trace system calls.
• KTRFAC_SYSRET — trace return values from system calls.
• KTRFAC_NAMEI — trace name lookup operations.
• KTRFAC_GENIO — trace all I/O. 🫣 note that this option can generate much output. like, SO much. your trace file is gonna be huge, be warned.
• KTRFAC_PSIG — trace posted signals.
• KTRFAC_CSW — trace context switch points.
• KTRFAC_USER — trace application-specific events.
• KTRFAC_STRUCT — trace certain data structures.
• KTRFAC_SYSCTL — trace sysctls.
• KTRFAC_PROCCTOR — trace process construction. 🐣
• KTRFAC_PROCDTOR — trace process destruction. 💀
• KTRFAC_CAPFAIL — trace capability failures.
• KTRFAC_FAULT — trace page faults.
• KTRFAC_FAULTEND — trace the end of page faults.
• KTRFAC_INHERIT — inherit tracing to future children. it's hereditary, iykyk. 🧬

Each tracing event outputs a record composed of a generic header followed by a trace point specific structure. The generic header is:

struct ktr_header {
        int             ktr_len;                /* length of buf */
        short           ktr_type;               /* trace record type */
        pid_t           ktr_pid;                /* process id */
        char            ktr_comm[MAXCOMLEN+1];  /* command name */
        struct timeval  ktr_time;               /* timestamp */
        intptr_t        ktr_tid;                /* was ktr_buffer */
};

and what do all those lil fields mean, you ask? 🎀

• ktr_len — the length of the ktr_type data that follows this header.
• ktr_pid and ktr_comm — the process and command generating the record.
• ktr_time — the time (with microsecond resolution) that the record was generated.
• ktr_tid — holds a thread id.

The generic header is followed by ktr_len bytes of a ktr_type record. The type specific records are defined in the <sys/ktrace.h> include file. go read it, it's iconic. ⭐

---

🌈 SYSCTL TUNABLES 🌈

these sysctl(8) tunables are the ones that influence the behaviour of ktrace():

• kern.ktrace.geniosize — bounds the amount of data a traced I/O request will log to the trace file.
• kern.ktrace.request_pool — bounds the number of trace events being logged at a time.

Sysctl tunables that control process debuggability (as determined by p_candebug(9)) also affect the operation of ktrace(). so many levers, so much power. ✨

---

💖 RETURN VALUES 💖

The ktrace() function returns the value 0 if successful; otherwise the value -1 is returned and the global variable errno is set to indicate the error. classic. zero means we ate, negative one means we're crying. 😭

---

💅 ERRORS 💅

The ktrace() system call will fail if:

• [ENOTDIR] — a component of the path prefix is not a directory.
• [ENAMETOOLONG] — a component of a pathname exceeded 255 characters, or an entire path name exceeded 1023 characters.
• [ENOENT] — the named tracefile does not exist.
• [EACCES] — search permission is denied for a component of the path prefix.
• [ELOOP] — too many symbolic links were encountered in translating the pathname.
• [EIO] — an I/O error occurred while reading from or writing to the file system.
• [EINTEGRITY] — corrupted data was detected while reading from the file system. 🫠
• [ENOSYS] — the kernel was not compiled with ktrace support. (rip, no tracing for you.)

🚨 also important, bestie: a thread may be unable to log one or more tracing events due to a temporary shortage of resources. This condition is remembered by the kernel, and the next tracing request that succeeds will have the flag KTR_DROP set in its ktr_type field. so if you see KTR_DROP, that's your sign that something got dropped. not dramatic, just facts.

---

👀 SEE ALSO 👀

• kdump(1)
• ktrace(1)
• utrace(2)
• sysctl(8)
• p_candebug(9)

go read those too, they're the supporting cast and they're all main characters. 🫶

---

🎀 HISTORY 🎀

The ktrace() system call first appeared in 4.4BSD. a true elder icon. 👑

---

okay that's the whole page bestie, you're officially a tracing girly now. this Debian version is dated March 30, 2020, and yeah it's still living rent free in section 2 of the manual. go forth and trace, but only your own processes. 💜🦋