On Windows, Autoruns is the name most people reach for when they need to see what launches at boot. On 5 November Microsoft brought it to Linux, and the version number started over: what had climbed to 14.x came back as 1.0.

Linux never kept its startup entries in one place

Windows spreads autostart across the registry and a handful of fixed folders, yet a single tool can still walk all of it in one pass. Linux does not work that way. Services go through systemd, older machines still carry SysV scripts, scheduled work lives in cron and anacron, desktop sessions read the XDG autostart directory, a login shell pulls in files such as .profile, and on top of that sit browser extensions, udev rules and the mount options declared in fstab. No single component owns the whole picture, so the question of what really starts when the machine boots used to mean crawling one location after another.

It pulls the scattered locations into one table

Autoruns for Linux is a command line tool written in Rust and released under the MIT license. It reads the configuration behind all of those locations and lays it out row by row: event, activation mechanism, target, principal, effective state, and where the evidence came from. Coverage reaches the XDG desktop autostart entries together with system wide and per user shell startup files; systemd system and user services, timers, sockets, paths, devices, mounts and automounts, including priority, mask state, drop-ins, dependencies, template instances and per stage conditions; cron, anacron and run-parts jobs at both levels; modules-load configuration, boot and SysV hooks, the dynamic loader preload list and search path, alternatives, and the supported network hook directories.

Browsers get their own treatment. Extensions for the Chromium family and for Firefox are listed across installations, users and profiles, and that takes in enterprise policy, external registration, resident load-extension launchers and native messaging hosts. On the device and media side it covers executable udev actions and units, the x-systemd relationships declared in fstab, autofs program maps, and the autorun priority on mounted media. Office suites are not left out either: LibreOffice and OpenOffice extension bundles, UNO components, and their event and task configuration all show up.

By default it only looks at login items

Running it with no arguments is the same as asking for login startup entries, which keeps it aligned with the default behaviour of the Windows build. To sweep every Linux category it implements, add -a together with a wildcard; you can also pick them one at a time with b, h, i, k, l, n, o, s and t, standing for boot hooks, image hijacks and preload, browser integration, dynamic loader, login items, network hooks, application integration, services and modules, and scheduled tasks. Devices and mounts have their own named selectors: device, mount, or device-mount.

Five output formats are available: CSV, TSV, JSON, XML and an aligned table, all carrying the same fields. The first 12 columns are the machine readable ones; after them come event, mechanism, principal, profile, activator, target and an integrity note, then the target state, whether the target exists, and whether it is executable. Targets given as absolute paths are checked inside the selected root and reported as present, missing or unreachable, while relative commands are marked unresolved. One detail is worth pointing out: registration state and target state are tracked separately, so an entry that is enabled while its file is gone still shows as enabled and is flagged for a missing target at the same time.

It reads, it does not act

Heavy handedness is the failure mode that ruins tools like this one. Autoruns for Linux limits itself to static file inspection: it does not run the commands it finds, does not start units, does not synthesise device events, does not mount media and does not load extensions. Text sources and XPI or OXT metadata are read under caps on file size, member count, single member size and total decompressed volume, and the metadata of target files is examined without being executed. Runtime service state is not queried at all, and under an offline root it could not be, which the output states plainly.

You can scan another system without booting it

The root argument points the scan at a different root directory, which makes test environments, already mounted systems, containers and offline images all fair game. That path is validated and normalised before scanning, and on Linux it goes through openat2 with RESOLVE_IN_ROOT and RESOLVE_NO_MAGICLINKS. On a kernel without that facility it emits a partial scan diagnostic and asks that a mounted image stay read only for the duration of the fallback. Exit codes are separated as well: 0 means the selected static adapters completed, 1 is an output failure, 2 is a bad argument or root directory, and 3 signals partial results.

What it does when something is out of scope

The trust options and the VirusTotal lookup of the Windows build have no counterpart here. Rather than pretend otherwise, the tool refuses them outright with exit code 2. Categories that exist only on Windows, and the parts the static adapters cannot reach, produce an explicit unsupported-scope line instead of being forced into some plausible looking category. The d selector keeps the compatible meaning it has on Windows and is not quietly repointed at devices.

Saying no when you cannot do something matters more for a diagnostic tool than adding a few more categories, because the most common mistake in startup investigations is treating what was not found as what is not there.

Who this is for

Operations teams come first: when a machine takes longer and longer to boot, or something is suspected of sitting resident without permission, one list that puts systemd, cron, desktop autostart and browser extensions side by side beats walking directories by hand. Security and forensics work fits too, since the root argument can point straight at a mounted image or a container root filesystem without bringing that system up first. Anyone trimming a distribution or slimming an image can use it as a baseline as well, to see how much is configured to start on its own out of the box.

Fifteen years of Windows coverage do not transfer to Linux, where the mechanisms were never the same. The idea of seeing autostart in one place does transfer, though, and the breadth of this 1.0 suggests Microsoft did more than a careless port.

What Autoruns is worth on Linux has less to do with how many autostart locations it recognises than with the fact that it stays read only and labels the places where it cannot be sure. A diagnostic tool earns trust through the limits it admits.