KDUMP(1)

💅 KDUMP(1) — the general commands manual, bestie edition 🎀

okay so real talk: this is kdump, from the General Commands Manual, and she's about to make your kernel trace files make sense. 🦋

✨ NAME ✨

kdump — display kernel trace data. that's it. that's the vibe. she reads the tea that ktrace spilled. 💖

🌸 SYNOPSIS 🌸

kdump [-dEnlHRSsTA] [-f trfile] [-m maxdata] [-p pid] [-t trstr]

💜 DESCRIPTION 💜

the kdump command displays the kernel trace files produced with ktrace(1) in human readable format. like, it takes the raw ✨vibes✨ the kernel scribbled down and translates them into actual sentences you can read. by default, the file ktrace.out in the current directory is displayed. no cap. 👑

the options are as follows, and yes we're going through every single one because that's the whole point:

• -A — Display the ABI of the traced process. gotta know what era this process is from 🫶
• -c — Display the CPU number with each trace entry. which core was doing the thing? now you know 💅
• -d — Display all numbers in decimal. no hex brainrot. just base-10 clarity ✨
• -E — Display elapsed timestamps (time since beginning of trace). like a stopwatch for the whole saga ⏱️
• -f trfile — Display the specified file instead of ktrace.out. your file, your rules 🎀
• -H — List the thread ID (tid) of the thread with each trace record, if available. If no thread ID is available, 0 will be printed. (yes, literally 0. she's doing her best 😭)
• -l — Loop reading the trace file, once the end-of-file is reached, waiting for more data. she's not leaving the group chat, she's just lurking for the next message 👀
• -m maxdata — Display at most maxdata bytes when decoding I/O. boundaries, bestie. we love them 💖
• -n — Suppress ad hoc translations. Normally kdump tries to decode many system calls into a more human readable format. For example, ioctl(2) values are replaced with the macro name and errno values are replaced with the strerror(3) string. Suppressing this feature yields a more consistent output format and is easily amenable to further processing. basically: raw mode, for when you're piping her into something and need her to be professional 🧚
• -p pid — Display only trace events that correspond to the process or thread pid. This may be useful when there are multiple processes or threads recorded in the same trace file. selective listening, iconic behavior 🙈
• -R — Display relative timestamps (time since previous entry). how long since the last message? ⏳
• -r — When decoding STRU records, display structure members such as UIDs, GIDs, dates etc. symbolically instead of numerically. names not numbers, we love a glow-up 🌈
• -S — Display system call numbers. the digits behind the drama 🔥
• -s — Suppress display of I/O data. sometimes you just don't need to see the receipts 💀
• -T — Display absolute timestamps for each entry (seconds since epoch). the big clock. the real clock. ⭐
• -t trstr — See the -t option of ktrace(1). go ask her sister, she explains it better 🫶

---

🦋 the output format, explained like we're on FaceTime 🦋

the output format of kdump is line oriented with several fields. the example below shows a section of a kdump generated by the following commands:

?> ktrace echo "ktrace"

?> kdump

 85045 echo     CALL  writev(0x1,0x804b030,0x2)
 85045 echo     GIO   fd 1 wrote 7 bytes
       "ktrace
       "
 85045 echo     RET   writev 7

so let's break down the fields, because they're lowkey doing a lot:

• the first field is the PID of the process being traced. 🏷️
• the second field is the name of the program being traced.
• the third field is the operation that the kernel performed on behalf of the process.
• also, if thread IDs are being printed, then an additional thread ID column will be added to the output between the PID field and program name field. surprise extra column! 🎁

In the first line above, the kernel executes the writev(2) system call on behalf of the process so this is a CALL operation. the fourth field shows the system call that was executed, including its arguments. the writev(2) system call takes a file descriptor, in this case 1, or standard output, then a pointer to the iovector to write, and the number of iovectors that are to be written. 🧠✨

In the second line we see the operation was GIO, for general I/O, and that file descriptor 1 had seven bytes written to it. This is followed by the seven bytes that were written, the string "ktrace" with a carriage return and line feed. (the lil line break in the quotes? that's the carriage return and line feed living their truth 💅)

the last line is the RET operation, showing a return from the kernel, what system call we are returning from, and the return value that the process received. Seven bytes were written by the writev(2) system call, so 7 is the return value. she ate and left no crumbs. 🍓

---

👑 the possible operations 👑

these are the operations you might catch in the wild, plus what shows up in the fourth field:

• CALL — enter syscall — fourth field: syscall name and arguments
• RET — return from syscall — fourth field: syscall name and return value
• NAMI — file name lookup — fourth field: path to file
• GIO — general I/O — fourth field: fd, read/write, number of bytes
• PSIG — signal — fourth field: signal name, handler, mask, code
• CSW — context switch — fourth field: stop/resume user/kernel wmesg
• USER — data from user process — fourth field: the data
• STRU — various syscalls — fourth field: structure
• SCTL — sysctl(3) requests — fourth field: MIB name
• PFLT — enter page fault — fourth field: fault address and type
• PRET — return from page fault — fourth field: fault result

👀 SEE ALSO 👀

ktrace(1) — the other half of this duo, go say hi 🫶

🌈 HISTORY 🌈

The kdump command appeared in 4.4BSD. vintage. antique. elder icon. she's been serving since before you were born 💜

---

ngl bestie, if you ever get confused: just run kdump and let her narrate. she literally explains the kernel to you. main character energy fr fr 💅✨

that's the whole page! this edition shipped from Debian and is dated July 16, 2022 — big love to the packagers, mwah 🎀