jetson-stats offers four install routes and three of them use root

Four install routes and three different reasons for root

The install section offers four options and the differences between them are the whole story. The first installs from the package index and says it needs superuser. The second installs from the GitHub repository, also under superuser. The third is the same thing with a flag added that overrides the externally managed environment protection a recent Ubuntu release enforces, so it exists for the distribution that broke the first two. The fourth is a different shape entirely: a shell script fetched with curl and piped into bash, described as installing it so that the tool runs with or without superuser and without that flag. Each route is two or three commands long and each assumes you understand why it exists, which the page does explain in a sentence each rather than a paragraph. The version check after the first one is a separate command, so a reader can tell which build they landed on.

Two routes pipe a script from the default branch into a shell

The fourth install route and the upgrade command both run a privileged credential refresh and then fetch a script from a raw file URL on the default branch, piping it straight into bash. On the branch rather than a tag, which means the content is whatever is there when you run it, and it is not covered by a release version. The upgrade command has the same shape and the same property, and it is the command a fleet operator would put in an image build, where an unpinned remote script is worth thinking about twice. The mitigations are also on the page: the credential refresh happens first so the script does not stop halfway for a password prompt, and the note about the newest developer kit tells you there is a further step for that hardware. That note is phrased as a follow rather than as a reason, which is easy to skim past.

The container is a client of a socket on the host

The Docker section is three steps and the third one is the interesting one. You install the package on the host, you install it inside the container as well, and then you pass a path into the container so that both sides see the same socket. The example run command binds exactly that path, and the documentation is explicit that this is how it works:

docker run --rm -it -v /run/jtop.sock:/run/jtop.sock rbonghi/jetson_stats:latest

So the container does not read the board's sensors. It talks to a service running on the host that does, which means the host install is not optional and the container is a presentation layer. That design is the right one for hardware access, where passing devices into a container is awkward, and it also means two moving parts: a version on the host and a version in the image, and the two have to agree about the socket's protocol.

No superuser needed, three lines above three sudo installs

The feature list has a line saying the tool does not need superuser, and it sits directly above the section that opens with a superuser install. Both statements are true and they are about different things. Reading the sensors does not require root on this hardware, which is what the feature list means, and installing into the system Python does, which is what the install commands mean. The fourth install route exists precisely to close that gap: it gets the tool installed without root so that the claim holds end to end. The part worth holding in mind is which features would need elevated rights anyway, and the list names them plainly, including fan speed control, the low power mode setting and the clock control command. So a user who takes the no root claim as covering the whole feature set will find that some of the control features behave differently under a plain account.

Three dependencies, one per hardware path

The requirements list is three lines long and each one is there for a reason. One is a bus library, which is how the fan and the board's own sensors are reached. One detects which Linux distribution is running, which matters on a platform where the same board image ships with different userlands. One is the vendor's management interface library, and that is where the graphics metrics come from rather than from parsing anything the project writes itself. A project with hardware access on three platforms and a terminal interface having three runtime dependencies is unusual, and the reason is that all the platform specific work has been pushed into those libraries. The example directory reflects the same shape: separate scripts for fan control, processor reading, graphics engine reading, memory, processes, board properties, a callback example, a server, a web server, a logger and a short read only sample.

The image pairs a current Python with an older Debian base

The container file is twenty lines and two of them decide the environment. The base image is the slim variant of a Python 3.13 image built on the Bullseye release of Debian, which is the previous stable release of that distribution rather than the current one. So the image ships a current interpreter on an older userland, and any system library the interpreter links against comes from that older release. Whether that matters depends on what you install into the container, and for this package, whose job is talking to a socket, it mostly does not. The rest of the file is a copy of the tree into the image, a single pip install of the project from that directory with verbose output, and a command that runs the tool. There is no user declaration and no volume, so the image runs as root by default.

The setup script still tests for a Python 2 marker

The build script is described in its own docstring as minimal, kept for backward compatibility and custom install commands, with the real configuration in the manifest. What it does that is worth reading is detect where it is running. It checks for a virtual environment by looking for the interpreter's base prefix attribute and comparing it with the current prefix, and also by looking for an attribute that only a Python 2 era virtual environment implementation defined. Then it checks for a container by looking for two well known marker files, one of which is the systemd one rather than the Docker one. None of this is wrong, and detecting both environments is sensible for an install script. The Python 2 check is the leftover: it tests for an attribute no supported interpreter has, so that branch can never fire, and it is still there because nobody has needed to remove it in a decade.

Editorial conclusion

Use jtop if you work with Jetson boards and want one view of processor, graphics, memory, engine and fan state that also doubles as a library and a container. Three things to know before you install it. The no root claim is about running the tool, not installing it, and the install still writes into the system Python, so pick the route that matches your distribution's rules about that. The container path does not read the hardware: it needs the package installed on the host and a socket passed in, so it is a client and not a substitute. And the two script routes fetch their content from the default branch at the moment you run them, which is convenient for a single board and worth pinning if you are provisioning a fleet.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes