How do I actually determine whether a vulnerable Java logging library is present anywhere on my server?

The layers, in the order I would run them:

1. Ask the package manager first. Whatever your distribution uses, query for the package by name. This catches anything installed the supported way and takes seconds. It also tells you the version, which the filesystem alone will not.

2. Search the filesystem for jar files matching the library name. Update your file index first if you are using an indexed search, otherwise you are querying yesterday's disk. Expect this to find vendor-bundled copies the package manager missed.

3. Search inside archives. This is the step people skip and it is where the real findings are. There are purpose-built scanners for exactly this problem that walk nested archives and check the classes inside rather than the filenames outside. Use one rather than writing your own — the nesting gets deep and the edge cases are numerous.

4. Ask what is actually running. List the running Java processes and look at their classpaths. A vulnerable jar sitting on disk that nothing loads is a lower priority than one in a live process.

Your instinct is right, and it is worth stating plainly: there is no single command that gives a trustworthy yes or no. Anyone who tells you otherwise is describing a first pass, not an answer.

The reason is packaging. A Java library can be present as:

• A file installed by your distribution's package manager, which is the easy case.
• A jar shipped inside a vendor's application directory, invisible to the package manager.
• A jar nested inside another archive — a war or ear or fat jar — so a filename search finds nothing.
• A class shaded into a completely differently-named artefact, where even the nested filename is gone.

Each of those needs a different detection method, and the last one defeats file-based searching entirely.

So the practical approach is layered, and you should treat each layer as reducing uncertainty rather than resolving it.

The structural lesson, which is the one worth taking away after the immediate scramble: this is an inventory problem, and you are solving it under time pressure because the inventory did not exist.

What makes the next one easier:

• Generate a software bill of materials for anything you build or deploy. Most build tools can emit a dependency list; store it with the artefact.
• Prefer distribution packages over vendor bundles where you have the choice, precisely so the package manager can answer questions like this one.
• Record what each server runs, at the application level, somewhere queryable. When the next advisory lands, the first question is always "where do we run this", and an hour of grep is a bad answer.

None of this helps today. All of it converts a two-day fire drill into a ten-minute query next time.