(Lightweight software usage monitoring)


tracker monitors usage of software by sending a UDP packet to a central server on port 1738 each time a binary is run. It should not be invoked directly; instead, the name of the program that the users invoke should be a symlink to tracker and the actual binary should be renamed by appending .t% to the name. This prefix is chosen to minimize the chances of conflicts with any other program.

The UDP packet sent will contain the username (from getpwuid) or UID of the invoking user and the name of the command that was invoked. It will be tagged with the IP address of the system (but of course that information is subject to NAT or other network infrastructure that changes packet IP addresses). The username is limited to 31 characters and the program name is limited to 255 characters.

tracker attempts to be as lightweight as possible and will run the actual program regardless of whether sending the UDP packet was successful. It uses an environment variable to try to prevent infinite recursion.

The name of the central logging server is set at compile time, and defaults to track.

Please note that this is not a licensing daemon or foolproof tracking system. A user who does not wish their usages to be tracked can always run the actual binary directly and bypass this tracking system. It's intended as a very lightweight way of answering questions like "is anyone using this any more?" or "about how many people run this program a day?"



Before invoking the actual program, tracker sets the environment variable TRACKING to the name of the program being run, a recursion depth, and the current time (separated by colons). When starting, it looks at this variable. If the program name matches the program being run, the timestamp is checked against the current time. If it is no more than one second different, the recursion depth is incremented. If the recursion depth reaches 10, tracker aborts without trying to invoke the program.

This is a safeguard against such things as tracker running itself. It isn't completely foolproof, but it's important to allow one tracked program to run another, or even itself if that isn't happening too fast (consider the case of tracking usage of xterm).



The current version of this program is available from its web page at <>.


Russ Allbery <>, based on a network protocol by Larry Schwimmer <>.

Last spun 2014-08-10 from POD modified 2014-04-14