xtruss(1)

✨ NAME ✨

xtruss — trace X protocol exchanges, in the manner of strace

hi bestie 💖 this one lives in the PuTTY spinoffs family, and it's about to become your whole personality, no cap.

---

🌸 SYNOPSIS 🌸

xtruss [ options ] command [ command-arguments ]
xtruss [ options ] -p X-resource-ID
xtruss [ options ] -p -
xtruss [ options ] -P

---

🦋 DESCRIPTION 🦋

so xtruss is a lil utility that logs literally everything that passes between the X server and one or more X client programs. it's giving xmon(1) energy, but the whole point is to take xmon's basic functionality and give it an interface way more like strace(1). slay.

like xmon, xtruss in its default mode works by setting up a proxy X server, waiting for connections to that, and forwarding them on to the real X server. BUT — and this is the iconic part — unlike xmon, you don't have to deal with any of that by hand 🫶 there's no need to start the trace utility in one terminal and manually attach processes to it from another, unless you really want to (in which case the -P option will do that). the principal mode of use is just to type xtruss followed by the command line of your X program; xtruss will automatically take care of adjusting the new program's environment to point at its proxy server, and (also unlike xmon) it will also take care of X authorisation automatically. main character energy fr fr.

as an alternative mode of use, you can also attach xtruss to an already-running X application, if you didn't realise you were going to want to trace it until it had already been started. this mode requires cooperation from the X server — specifically, it can't work unless the server supports the RECORD protocol extension — but since modern X.Org servers do provide that, it's often useful. 💅

the logging format of xtruss is much more compact than that of xmon, and resembles strace in that it's written to look like a series of function calls some of which return values. for instance, where xmon would print:

............REQUEST: GetSelectionOwner
    sequence number: 000f
     request length: 0002
          selection: <PRIMARY>
                        ..............REPLY: GetSelectionOwner
                            sequence number: 000f
                               reply length: 00000000
                                      owner: WIN 02c0002b
............REQUEST: InternAtom
    sequence number: 0010
     only-if-exists: False
     request length: 0005
     length of name: 000c
               name: "VT_SELECTION"
                        ..............REPLY: InternAtom
                            sequence number: 0010
                               reply length: 00000000
                                       atom: ATM 000002bf

xtruss will instead print:

GetSelectionOwner(selection=a#1) = {owner=w#02C0002B}
InternAtom(name="VT_SELECTION", only-if-exists=False) = {atom=a#703}

note that not only has each request been condensed on to one line (though most lines will be long enough to wrap, at least on a standard 80-column terminal), but also each request and reply have been printed on the same line. obsessed. 😭

that last is not always possible, of course: sometimes an application will queue multiple requests before receiving the reply to the first one (in fact, this is generally good behaviour since it minimises network round-trip delays), in which case xtruss's output will look — again mimicking strace — something like this:

InternAtom(name="TARGETS", only-if-exists=False) = <unfinished>
InternAtom(name="TIMESTAMP", only-if-exists=False) = <unfinished>
 ... InternAtom(name="TARGETS", only-if-exists=False) = {atom=a#378}
 ... InternAtom(name="TIMESTAMP", only-if-exists=False) = {atom=a#379}

---

🎀 OPTIONS 🎀

these options change the mode of operation of xtruss away from the default of acting as a wrapper on a single command:

• -p resource-ID — attach to the X client owning the given resource, using the X RECORD extension (which the server must support for this to work). the resource ID can be a decimal integer or a hex integer preceded with 0x. it typically names an X window, but can name another type of resource instead (e.g. a pixmap or cursor) or just specify the resource base of the client connection. if you don't know any of those things, you can give the resource ID as just -, in which case xtruss will let you interactively select a window by clicking with the mouse (similarly to xkill(1), xwininfo(1) and xprop(1)) and will trace the client that owns the window you select. 🖱️✨
• -P — set up a logging X proxy as in the normal mode, but instead of spawning a subprocess to connect to that proxy, just wait for connections. this turns xtruss into a tool more similar to xmon: you start it in one terminal window, and then from another terminal window you can configure selected processes to connect to the proxy server and be logged. xtruss will print on standard output the environment variables you need to set up to connect other processes to the proxy (in both sh and csh syntax). 👑

the following options apply to all modes of operation:

• -s length — limit the length of output lines by eliding most of the contents of long arrays, strings and blocks of data. xtruss will begin to shorten lines at the specified length (any line shorter than that should not be interfered with), but lines cannot always be chopped to the exact length and continue to make sense, so the line length is approximate only. specifying zero or unlimited will remove all restriction, so that xtruss will display the full contents of every request it understands, no matter how big. default is 256.
• -o filename — send the trace output to the specified file, or to standard output if filename is just -. the default is to log to standard error.
• -e [class=][!]item[,item...] — specify a subset of X requests or X events to log. class can be either requests or events; if the class is omitted, requests is assumed. the list of item gives a list of X request names or X event names (respectively) to be logged; all other requests or events are omitted. if the list of items is prefixed with !, it is instead treated as a list of requests or events not to be logged, and anything not in the list is printed. reply and error packets are not separately filtered: they are logged if and only if the request they respond to was logged.

for example, to log only ImageText8 and ImageText16 requests, you might say xtruss -e requests=ImageText8,ImageText16 command or just xtruss -e ImageText8,ImageText16 command. to inhibit the display of FocusIn and FocusOut events, you might say xtruss -e events=!FocusIn,FocusOut command.

(note that the ! character might be treated specially by your shell, so you may need to escape it.) 🙈

• -I — log the initialisation message sent by the X server at the start of the connection. this is omitted by default because it's particularly long and ugly. 💀
• -R — as well as translating the X protocol, also give a raw hex dump of all the data transferred over the connection. (probably most useful to include in a bug report about xtruss itself!) 🔥
• -C — prefix every output line with the X client id (resource base) of the client connection it came from. by default xtruss only starts to do this if it's tracing more than one X client; before then, lines are unprefixed. this option makes prefixing unconditional from the start of the run.

---

😭 BUGS 😭

many commonly used X protocol extensions are not currently decoded.

a lot of this program has been only minimally tested.

---

💜 LICENCE 💜

xtruss is free software, distributed under the MIT/X11 licence. type xtruss --licence to see the full licence text.

---

okay that's the whole page bestie 🌈 go forth and trace, you absolute icon — this one came to you courtesy of the PuTTY spinoffs and is dated 2009‐05‐02, mwah 💅💖🦋