Use lpinfo to inspect CUPS devices and legacy drivers

You will use lpinfo to ask a CUPS server which device URIs and printer driver records it knows about. This is an inspection task: it does not create a printer queue or change the server. Allow about ten minutes if CUPS is already running, or longer if you also need to identify why the server is unavailable.

This guide uses the installed cups-client package, version 2.4.7-1.2ubuntu7.14. The local CUPS manual calls lpinfo deprecated because printer drivers and backends are being retired from future CUPS feature releases. It remains useful for examining an existing CUPS 2.4 installation, but do not treat a driver listing as a recommendation for a new deployment.

1. Check the command without elevated privileges

Run the command as your normal user. Listing devices and models does not normally require sudo, and running it as root will not start CUPS or repair a missing server.

$ command -v lpinfo
/usr/bin/lpinfo
$ lpinfo --help
Usage: lpinfo [options] -m
       lpinfo [options] -v

The help text is a quick version-independent check that the client is installed. This build accepts short options and the long filtering options documented by the local manual. It does not provide a useful --version option, so use the package manager when you need the installed version:

$ dpkg-query -W -f='${Package} ${Version}\n' cups-client
cups-client 2.4.7-1.2ubuntu7.14

Checkpoint: if command -v finds nothing, stop here and install the client through your normal package-management process. Do not copy a driver URI from another machine as a substitute for a working local client.

2. List the device URIs known to CUPS

Use -v for devices. The output normally has a device class, a human-readable description and a URI. The URI is the value you would investigate before configuring a queue with a separate CUPS administration command.

$ lpinfo -v
<device-class> <description> <device-uri>

The exact lines depend on installed backends, connected hardware, network discovery and the CUPS server you contact. Do not expect lpinfo -v to find a printer merely because the printer is powered on. A network may block discovery, a backend may be absent, or the server may know no devices.

For a less open-ended query, select a server explicitly. The -h option must come before the other options:

$ lpinfo -h print.example.invalid:631 -v

Replace the placeholder with a real CUPS server name and port. This command is read-only, but it can contact a remote service, so use a server you are authorised to query. If the connection must be encrypted, add -E after -h:

$ lpinfo -h print.example.invalid:631 -E -v

Checkpoint: a successful result is a list of devices, not a queue name. Save the output if you are handing an administrator a candidate URI. A URI may contain credentials or other sensitive connection details; treat captured output as configuration data.

3. Limit discovery time and reduce noisy schemes

Device discovery can wait while a backend searches the network. Set a timeout in seconds when using -v:

$ lpinfo --timeout 10 -v

The timeout controls device listing. It does not make an unreachable CUPS server healthy, and it does not guarantee that every slow device will appear. For repeatable troubleshooting, record the server, timeout and date alongside the output.

You can include or exclude URI schemes with comma-delimited lists. The local manual identifies static PPD files as the file scheme. For example, this excludes static PPD entries from a device query:

$ lpinfo --exclude-schemes file -v

Use --include-schemes only with scheme names you have a reason to inspect. The option is a filter, not a request to load a backend. If you are unsure which schemes are present, run an unfiltered query first and compare the results.

4. List the legacy driver records

Use -m to list models and driver records known to the server:

$ lpinfo -m
OKIDATA 9-Pin Series  | drv:///sample.drv/okidata9.ppd
Zebra ZPL Label Printer  | drv:///sample.drv/zebra.ppd

Those records are examples of the output shape, not a promise that the same records exist on your server. The first field is descriptive text and the second is the model or PPD identifier. An available record does not prove that a printer supports every feature named by the description.

Filter the model list when you know part of the make and model:

$ lpinfo --make-and-model "HP LaserJet" -m

Other documented model filters are --device-id, --language and --product. They apply to -m, not -v. Long listings are available with -l:

$ lpinfo -l -m
$ lpinfo -l -v

Use the long form when the short result does not expose enough detail to compare records. Avoid assuming that a verbose record is current hardware metadata. It is still information returned by the CUPS server and its installed drivers.

5. Diagnose a failed query

First separate a client syntax error from a server or backend problem. This is a harmless local check:

$ lpinfo -h localhost -v
lpinfo: Bad file descriptor

On this machine, that result means the requested CUPS connection is not usable. Your wording may differ. Check the exit status immediately after the query, before running another command:

$ lpinfo -h localhost -v
$ status=$?
$ printf 'lpinfo exit status: %s\n' "$status"
lpinfo exit status: <status from this run>

Then inspect the service using your distribution's service and log tools, without changing anything:

$ systemctl is-active cups
$ systemctl status cups --no-pager

If the service is inactive, starting it is an administrative change and may affect other users. Confirm that this is the intended host and follow the local change procedure before using sudo systemctl start cups. If you only need to inspect a remote server, do not start a local service just to make the command succeed.

An empty or small result can also be normal. Discovery depends on backends and network visibility, while driver results depend on what the server has installed. Compare lpinfo -v with lpinfo -m rather than treating one list as proof that the other is broken.

6. Keep the boundary clear

lpinfo does not add, remove or enable printers. It does not install drivers, edit a PPD, change a queue, submit a job or alter a server configuration. There is therefore no undo command for the examples in this guide: they only query CUPS. The one exception is operational impact from probing a remote service, which is why a short timeout and an authorised server are sensible defaults.

For a new printer, prefer an IPP-based workflow supported by the printer and current CUPS architecture. If a legacy queue specifically requires a driver record, validate the device URI, model compatibility and security policy separately before an administrator creates the queue. CUPS upstream documents the driver and backend deprecation, so a successful lpinfo -m result should not be read as a long-term platform guarantee.