DTRACE_PROC(4)
π DTRACE_PROC(4) β like, the whole manual page, bestie
Hey bestie, so this is a page from the Kernel Interfaces Manual (yes, that's the manual name, we're fancy now) and it's all about dtrace_proc β a DTrace provider for tracing events related to user processes. Strap in π
β¨ SYNOPSIS β¨
Okay so here's the whole vibe, one probe at a time:
proc:::create(struct proc *, struct proc *, int);
proc:::exec(char *);
proc:::exec-failure(int);
proc:::exec-success(char *);
proc:::exit(int);
proc:::signal-clear(int, ksiginfo_t *);
proc:::signal-discard(struct thread *, struct proc *, int);
proc:::signal-send(struct thread *, struct proc *, int);
π¦ DESCRIPTION π¦
The DTrace proc provider gives you the inside scoop on user process events, like: process and thread creation and termination, and process signalling. Literally all the juicy process drama π₯
The proc:::create() probe fires when a user process is created via the fork(2), vfork(2), pdfork(2), or rfork(2) system calls. Super important caveat tho: kernel processes created with the kproc(9) KPI will not trigger this probe, no cap. The proc:::create() probe's first two arguments are the new child process and its parent, respectively (so args[0] = baby, args[1] = parent, iykyk πΆ). The third argument is a mask of rfork(2) flags indicating which process resources are to be shared between the parent and child processes.
The proc:::exec() probe fires when a process attempts to execute a file. Its argument is the specified filename for the file. If the attempt fails because of an error, the proc:::exec-failure() probe will subsequently fire, providing the corresponding errno(2) value in its first argument. Otherwise (success era β¨), the proc:::exec-success() probe will fire.
The proc:::exit() probe fires when a process exits or is terminated. Its argument is the corresponding SIGCHLD signal code; valid values are documented in the siginfo(3) manual page and defined in signal.h. For example, when a process exits normally, the value of args[0] will be CLD_EXITED. Slay, clean exit π
The proc:::signal-send() probe fires when a signal is about to be sent to a process. The proc:::signal-discard() probe fires when a signal is sent to a process that ignores it β rude of them tbh π. This probe will fire after the proc:::signal-send() probe for the signal in question. The arguments to these probes are the thread and process to which the signal will be sent, and the signal number of the signal. Valid signal numbers are defined in the signal(3) manual page. The proc:::signal-clear() probe fires when a pending signal has been cleared by one of the sigwait(2), sigtimedwait(2), or sigwaitinfo(2) system calls. Its arguments are the signal number of the cleared signal, and a pointer to the corresponding signal information. You can get the siginfo_t for the signal from args[1]->ksi_info β yes, exactly like that, bestie π
π ARGUMENTS π
Okay so even though the proc provider probes use native FreeBSD arguments types, standard D types for processes and threads are available π These are psinfo_t and lwpsinfo_t respectively, and they're defined in /usr/lib/dtrace/psinfo.d. That file also defines two global variables, curpsinfo and curlwpsinfo, which provide representations of the current process and thread using these types. Iconic.
πΈ The fields of psinfo_t are:
int pr_nlwpβ Number of threads in the process.pid_t pr_pidβ Process ID.pid_t pr_ppidβ Process ID of the parent process, or0if the process does not have a parent.pid_t pr_pgidβ Process ID of the process group leader.pid_t pr_sidβ Session ID, or0if the process does not belong to a session.pid_t pr_uidβ Real user ID.pid_t pr_euidβ Effective user ID.pid_t pr_gidβ Real group ID.pid_t pr_egidβ Effective group ID.uintptr_t pr_addrβ Pointer to thestruct procfor the process.string pr_psargsβ Process arguments.u_int pr_arglenβ Length of the process argument string.u_int pr_jailidβ Jail ID of the process.
π§ The fields of lwpsinfo_t are:
id_t pr_lwpidβ Thread ID.int pr_flagβ Thread flags.int pr_priβ Real scheduling priority of the thread.char pr_stateβ Currently always0.char pr_snameβ Currently always'?'.short pr_syscallβ Currently always0.uintptr_t pr_addrβ Pointer to thestruct threadfor the thread.uintptr_t pr_wchanβ Current wait address on which the thread is sleeping.
π FILES π
/usr/lib/dtrace/psinfo.dβ DTrace type and translator definitions for theprocprovider.
(That's the whole list. One file. She's lowkey carrying the entire operation π )
β EXAMPLES β
The following script logs process execution events as they occur β copy it, run it, obsess over it:
#pragma D option quiet
proc:::exec-success
{
printf("%s", curpsinfo->pr_psargs);
}
Heads up bestie: thepr_psargsfield is subject to the limit defined by thekern.ps_arg_cache_limitsysctl. In particular, processes with an argument list longer than the value defined by this sysctl cannot be logged in this way. So if your args are too long, it's giving nothing, no data for you π
π COMPATIBILITY π
The proc provider in FreeBSD is not compatible with the proc provider in Solaris. Not even a little. In particular, FreeBSD uses the native struct proc and struct thread types for probe arguments rather than translated types. Additionally, a number of proc provider probes found in Solaris are not currently available on FreeBSD. Different lore, different era π
π₯ SEE ALSO π₯
dtrace(1), errno(2), fork(2), pdfork(2), rfork(2), vfork(2), siginfo(3), signal(3), dtrace_sched(4), kproc(9)
Read them all, bestie, they're all linked π
π°οΈ HISTORY π°οΈ
The proc provider first appeared in FreeBSD 7.1. Vintage. Elder emoji energy π
π«Ά AUTHORS π«Ά
This manual page was written by Mark Johnston <markj@FreeBSD.org>. Thank you Mark, king behavior π
Okay that's the whole page babes!! Written for the Debian manual, dated March 3, 2023, filed under DTRACE_PROC(4) β go trace some processes, you got this, periodt β¨π
π
π¦ where this page comes from
- freebsd 14.5: base 14.5
- freebsd 15.1: base 15.1
- nixpkgs unstable: source
- Copyright (c) 2015 Mark Johnston <markj@FreeBSD.org>
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms