How to reliably identify the process name for print jobs in CUPS?

[CreativeTest827]

Hi everyone,

I'm currently working on monitoring and analyzing print jobs handled by CUPS, and I wanted to discuss an approach I'm experimenting with and get your feedback.

My Current Approach

Right now, I am tracking print activity by reading files directly from:

/var/spool/cups

Specifically:

I monitor newly created spool files
Extract and log:
Filename
Printer name

This gives me visibility into what is being printed and where it is going.

Problem

However, I am missing a critical piece of information:

👉 Which process/application initiated the print job?

For example:

Was it Firefox?
LibreOffice?
Chrome?
Some background service?

CUPS itself does not seem to directly expose the originating process name in an easy way.

What I’m Trying to Achieve

I want to reliably map:

Print Job → Process Name (Application)
Ideas I’m Exploring
Monitoring /var/spool/cups (current approach)
Correlating with:
/proc filesystem
Open file descriptors
Active UNIX sockets connected to CUPS
Using fanotify to trace file access or socket communication
Questions
Is there a recommended or built-in way in CUPS to identify the originating process of a print job?
Has anyone implemented process attribution for print jobs in Linux?
Would correlating CUPS socket connections (/run/cups/cups.sock) with processes be a reliable approach?
Are there better alternatives than monitoring spool files?
Goal

I’m aiming for a reliable and real-time method to identify the application responsible for each print job.

Any insights, suggestions, or pointers would be greatly appreciated!

Thanks in advance 🙌

[michaelrsweet]

First, directly accessing the spool directory is a recipe for trouble - you need to be root and you are depending on the format, naming, and location of files to not change (and it is changing in a big way starting with CUPS 3.0...)

That said, there is currently no way to reliably obtain the submitting process of a print job - jobs submitted via local domain socket on Linux and macOS provide address to the pid, uid, and gid of the caller, but many applications use a D-Bus print dialog interface for printing which isolates the submitting application from the local domain socket. Similarly, network-submitted jobs will have no such information. There is an opt-in informational attribute ("client-info") that applications can use to supply identifying information, however no application I am aware of currently produces it.