cups-browsed.conf(5)
π NAME π
Okay bestie, gather round, because this is the manual page for cups-browsed.conf(5) β aka the server configuration file for cups-browsed π«Ά
πΈ DESCRIPTION πΈ
The cups-browsed.conf file is literally the vibe-setter for the cups-browsed daemon. It normally lives in the /etc/cups directory, living its little life there.
Every single line in the file can be one of three things:
- a configuration directive β¨
- a blank line (yes, blank lines are valid, they're just chillin')
- a comment
Comment lines start with the # character. That's the whole rule. # at the start = not a directive, just you talking to yourself π
π DIRECTIVES π
π CacheDir
The "CacheDir" directive decides where cups-browsed should save information about the print queues it had generated when shutting down β like whether one of these queues was the default printer, or default option settings of the queues. Basically it's the little memory box it packs up before it goes to sleep π΄
CacheDir /var/cache/cups-browsed
π LogDir
With "LogDir" you can define where cups-browsed creates its debug log file β but only if "DebugLogging file" is set. No file mode, no log file, no drama.
LogDir /var/log/cups-browsed
π DebugLogging
The "DebugLogging" directive determines how debug logging should be done. Your options, bestie:
- into the file
/var/log/cups-browsed/cups-browsed_logβ that's"file" - to stderr β that's
"stderr" - or not at all β that's
"none"
Heads up! Ifcups-browsedis running as a system service (for example via systemd), logging to stderr makes the log output go to the journal or syslog instead. Only if you runcups-browsedfrom the command line (for development or debugging) will it actually appear on stderr. iykyk π₯
DebugLogging file
DebugLogging stderr
DebugLogging file stderr
DebugLogging none
π¦ BrowseAllow, BrowseDeny, and BrowseOrder
Only browse remote printers (via DNS-SD) from selected servers using the "BrowseAllow", "BrowseDeny", and "BrowseOrder" directives.
This serves for restricting the choice of printers in print dialogs to trusted servers, or to reduce the number of listed printers in the print dialogs to a more user-friendly amount in large networks with very many shared printers. No cap, some networks have SO many printers it's giving chaos π
Important caveat, bestie: this only filters the selection of remote printers for whichcups-browsedcreates local queues. If the print dialog uses other mechanisms to list remote printers β as for example direct DNS-SD access βcups-browsedhas no influence.cups-browsedalso does not prevent the user from manually accessing non-listed printers. The main character energy here is limited, periodt.
"BrowseAllow"β Accept printers from these hosts or networks. If there are only"BrowseAllow"lines and no"BrowseOrder"and/or"BrowseDeny"lines, only servers matching at last one"BrowseAllow"line are accepted."BrowseDeny"β Deny printers from these hosts or networks. If there are only"BrowseDeny"lines and no"BrowseOrder"and/or"BrowseAllow"lines, all servers NOT matching any of the"BrowseDeny"lines are accepted."BrowseOrder"β Determine the order in which"BrowseAllow"and"BrowseDeny"lines are applied. With"BrowseOrder Deny,Allow"in the beginning all servers are accepted, then the"BrowseDeny"lines are applied to exclude unwished servers or networks and after that the"BrowseAllow"lines to re-include servers or networks. With"BrowseOrder Allow,Deny"we start with denying all servers, then applying the"BrowseAllow"lines and afterwards the"BrowseDeny"lines.
Default for "BrowseOrder" is "Deny.Allow" if there are both "BrowseAllow" and "BrowseDeny" lines.
If there are no "Browse..." lines at all, all servers are accepted. Everyone's invited to the party π
BrowseAllow All
BrowseAllow 192.168.7.20
BrowseAllow 192.168.7.0/24
BrowseAllow 192.168.7.0/255.255.255.0
BrowseDeny All
BrowseDeny 192.168.1.13
BrowseDeny 192.168.3.0/24
BrowseDeny 192.168.3.0/255.255.255.0
BrowseOrder Deny,Allow
BrowseOrder Allow,Deny
π§ Filtering remote printers by other properties than IP addresses of their servers
Often the desired selection of printers cannot be reached by only taking into account the IP addresses of the servers. For these cases there is the BrowseFilter directive, to filter by most of the known properties of the printer. It's giving β¨customizationβ¨
By default there is no BrowseFilter line, meaning that no filtering is applied.
To do filtering one can supply one or more BrowseFilter directives like this:
BrowseFilter [NOT] [EXACT] <FIELD> [<VALUE>]
The BrowseFilter directive always starts with the word "BrowseFilter" and it must at least contain the name of the data field (<FIELD>) of the printer's properties to which it should apply.
Available field names are:
name: Name of the local print queue to be created
host: Host name of the remote print server
port: Port through which the printer is accessed on the server
service: DNS/SD service name of the remote printer
domain: Domain of the remote print server
Also all field names in the TXT records of DNS-SD-advertised printers are valid, like "color", "duplex", "pdl", ... If the field name of the filter rule does not exist for the printer, the rule is skipped. No field, no problem, we move on π
The optional <VALUE> field is either the exact value (when the option EXACT is supplied) or a regular expression (run man 7 regex in a terminal window) to be matched with the data field.
If no <VALUE> filed is supplied, rules with field names of the TXT record are considered for boolean matching (true/false) of boolean field (like duplex, which can have the values "T" for true and "F" for false).
If the option NOT is supplied, the filter rule is fulfilled if the regular expression or the exact value DOES NOT match the content of the data field. In a boolean rule (without <VALUE>) the rule matches false.
Regular expressions are always considered case-insensitive and extended POSIX regular expressions. Field names and options (NOT, EXACT) are all evaluated case-insensitive. If there is an error in a regular expression, the BrowseFilter line gets ignored.
Especially to note is that supplying any simple string consisting of only letters, numbers, spaces, and some basic special characters as a regular expression matches if it is contained somewhere in the data field.
If there is more than one BrowseFilter directive, ALL the directives need to be fulfilled for the remote printer to be accepted. If one is not fulfilled, the printer will get ignored. It's an all-or-nothing situation, bestie π
β Examples
Rules for standard data items which are supplied with any remote printer advertised via DNS-SD:
Print queue name must contain "hum_res_", this matches "hum_res_mono" or "hum_res_color" but also "old_hum_res_mono":
BrowseFilter name hum_res_
This matches if the remote host name contains "printserver", like "printserver.local", "printserver2.example.com", "newprintserver":
BrowseFilter host printserver
This matches all ports with 631 in their number, for example 631, 8631, 10631,...:
BrowseFilter port 631
This rule matches if the DNS-SD service name contains "@ printserver":
Browsefilter service @ printserver
Matches all domains with "local" in their names, not only "local" but also things like "printlocally.com":
BrowseFilter domain local
β Examples for rules applying to items of the TXT record
This rule selects PostScript printers, as the "PDL" field in the TXT record contains "postscript" then. This includes also remote CUPS queues which accept PostScript, independent of whether the physical printer behind the CUPS queue accepts PostScript or not.
BrowseFilter pdl postscript
Color printers usually contain a "Color" entry set to "T" (for true) in the TXT record. This rule selects them:
BrowseFilter color
This is a similar rule to select only duplex (automatic double-sided printing) printers:
BrowseFilter duplex
β Rules with the NOT option
This rule EXCLUDES printers from all hosts containing "financial" in their names, nice to get rid of the 100s of printers of the financial department:
BrowseFilter NOT host financial
Get only monochrome printers ("Color" set to "F", meaning false, in the TXT record):
BrowseFilter NOT color
β Rules with more advanced use of regular expressions
Only queue names which BEGIN WITH "hum_res_" are accepted now, so we still get "hum_res_mono" or "hum_res_color" but not "old_hum_res_mono" any more:
BrowseFilter name ^hum_res_
Server names is accepted if it contains "print_server" OR "graphics_dep_server":
BrowseFilter host print_server|graphics_dep_server
"printserver1", "printserver2", and "printserver3", nothing else:
BrowseFilter host ^printserver[1-3]$
Printers understanding at least one of PostScript, PCL, or PDF:
BrowseFilter pdl postscript|pcl|pdf
β Examples for the EXACT option
Only printers from "printserver.local" are accepted:
BrowseFilter EXACT host printserver.local
Printers from all servers except "prinserver2.local" are accepted:
BrowseFilter NOT EXACT host prinserver2.local
π BrowsePoll
The BrowsePoll directive polls a server for available printers once every 60 seconds. Multiple BrowsePoll directives can be specified to poll multiple servers. The default port to connect to is 631.
BrowsePoll 192.168.7.20
BrowsePoll 192.168.7.65:631
BrowsePoll host.example.com:631
π BrowseLocalProtocols
The BrowseLocalProtocols directive specifies the protocols to use when advertising local shared printers on the network. The default is "none". Control of advertising of local shared printers using dnssd is done by CUPS and configured in /etc/cups/cupsd.conf.
BrowseLocalProtocols none
π BrowseRemoteProtocols
The BrowseRemoteProtocols directive specifies the protocols to use when finding remote shared printers on the network. Multiple protocols can be specified by separating them with spaces. The default is "dnssd".
BrowseRemoteProtocols none
BrowseRemoteProtocols dnssd
π BrowseProtocols
The BrowseProtocols directive specifies the protocols to use when finding remote shared printers on the network and advertising local shared printers. Multiple protocols can be specified by separating them with spaces.
BrowseProtocols none
BrowseProtocols dnssd
π DomainSocket
The DomainSocket directive specifies the domain socket through which the locally running CUPS daemon is accessed. If not specified the standard domain socket of CUPS is used. Use this if you have specified an alternative domain socket for CUPS via a Listen directive in /etc/cups/cupsd.conf. If cups-browsed is not able to access the local CUPS daemon via a domain socket it accesses it via localhost. "None" or "Off" lets cups-browsed not use CUPS' domain socket.
DomainSocket /var/run/cups/cups.sock
DomainSocket None
DomainSocket Off
The HTTP timeouts are for requests cups-browsed sends out to local and remote resources, in seconds. So there's two of them:
HttpLocalTimeout 5
HttpRemoteTimeout 10
β οΈ Bestie, listen: too-short timeouts mean services that are actually there get missed, and operations get repeated for absolutely no reason. Too-long timeouts mean everything drags forever when the server's justβ¦ not responding. Pick wisely. π
Next: how many retries (that's the N) cups-browsed does when it's creating print queues for remote printers that keep timing out mid-creation. Printers that still aren't set up after all N retries get skipped until the service restarts. Also, too many retries = high CPU load. Just so you know.
HttpMaxRetries 5
Wanna change how often the browsing/broadcasting cycles happen β local, remote, or both? That's the BrowseInterval directive's whole job.
BrowseInterval 60
Then BrowseTimeout sets how many seconds browsing-related operations are allowed to take. And heads up on the counting: adding or removing one printer queue = one operation. The timeout applies to each one of those individually, not the whole batch. π«Ά
BrowseTimeout 300
AllowResharingRemoteCUPSPrinters decides whether a print queue that points at a remote CUPS queue gets re-shared onto the local network or not. And because queues made with the BrowsePoll directive are also pointing at remote queues, they get shared automatically too if this is on. Default? Not sharing remote queues. β¨
AllowResharingRemoteCUPSPrinters Yes
NewBrowsePollQueuesShared decides whether a print queue for a newly discovered printer (discovered via BrowsePoll) gets shared to the local network. Important: this only does anything if AllowResharingRemoteCUPSPrinters is set to yes. Default is not sharing printers discovered via BrowsePoll.
NewBrowsePollQueuesShared Yes
Okay, OnlyUnsupportedByCUPS time. Set it to "Yes" and cups-browsed will not create local queues for remote printers that CUPS already makes queues for all by itself. Which printers are those? The ones advertised via DNS-SD that do CUPS-supported driverless printing β currently that's PWG Raster and Apple Raster β and that includes remote CUPS queues. Queues for other printers (think legacy PostScript/PCL girlies) are always created, depending on the other config settings in cups-browsed. πΈ
Flip OnlyUnsupportedByCUPS to "No" and cups-browsed creates queues for every printer it supports, even the ones CUPS would handle itself. Temporary queues made by CUPS get overwritten. Why would you want that? Because it guarantees any extra cups-browsed functionality applies to those queues. And since cups-browsed queues are permanent CUPS queues, this setting is also the move if you've got apps/print dialogs installed that don't support temporary CUPS queues. Fun fact: this is the default. π
OnlyUnsupportedByCUPS Yes
Now UseCUPSGeneratedPPDs set to "Yes" makes cups-browsed create queues for IPP printers using PPDs generated by CUPS' own PPD generator instead of cups-browsed's. Upside: any new development in CUPS' PPD generator is instantly available to you. The catch is that CUPS' PPD generator isn't directly accessible, so we have to make CUPS generate a temporary print queue with the PPD we want. Which means we can only use these PPDs when our queue replaces a temporary CUPS queue β so the queue has to be for a printer where CUPS supports driverless printing (IPP 2.x, PDLs: PDF, PWG Raster, and/or Apple Raster), and its name has to match what CUPS uses for the temporary queue (so "LocalQueueNamingIPPPrinter DNS-SD" must be set). This directive only applies to IPP printers, not to remote CUPS queues β that's so clustering doesn't break. Set it to "No" and cups-browsed generates the PPD itself. Default is "No". π
UseCUPSGeneratedPPDs No
LocalQueueNamingRemoteCUPS and LocalQueueNamingIPPPrinter are how you control the names of local queues cups-browsed generates β separately for remote CUPS printers and for IPP printers. Naming, but make it modular.
"DNS-SD"β the default for both β bases the name on the service name in the printer's advertised DNS-SD record. This is exactly the same naming scheme CUPS uses for its temporary queues, so the local queue from cups-browsed stops CUPS from listing and creating a second queue. And since DNS-SD service names have to be unique, queue names of printers from different servers will be unique too β which means no automatic clustering for load-balanced printing."MakeModel"bases the queue name on the printer's manufacturer and model names. This is the scheme cups-browsed used back in the day for IPP printers."RemoteName"β only available for remote CUPS queues β uses the name of the queue on the remote CUPS server as the local queue's name. This makes printers on different CUPS servers with equal queue names automatically form a load-balancing cluster, just like CUPS did formerly (CUPS 1.5.x and older) with CUPS-broadcasted remote printers. Again: the scheme cups-browsed used formerly for remote CUPS printers.
LocalQueueNamingRemoteCUPS DNS-SD
LocalQueueNamingRemoteCUPS MakeModel
LocalQueueNamingRemoteCUPS RemoteName
LocalQueueNamingIPPPrinter DNS-SD
LocalQueueNamingIPPPrinter MakeModel
DNSSDBasedDeviceURIs to "Yes" means cups-browsed uses DNS-SD-service-name-based device URIs for its local queues, same as CUPS does. Those queues use the DNS-SD service name of the discovered printer. The glow-up here: the URI is independent of network interfaces and ports, so you get reliable connections to always the same physical device. This setting is the default. β¨
Set it to "No" and cups-browsed uses the conventional host-name/IP-based URIs instead.
Heads up bestie: this option only affects URIs for printers discovered via DNS-SD, not via BrowsePoll. Those printers always get the conventional URIs. No exceptions. π
DNSSDBasedDeviceURIs Yes
Set IPBasedDeviceURIs to "Yes" and cups-browsed creates local queues with device URIs that use the IP addresses instead of the host names of the remote servers. This mode exists for any host name resolution problems in the network β especially if avahi-daemon is only run for printer discovery and already stopped while you're still printing. By default this mode is off, meaning we use URIs with host names.
Note that IP addresses depend on the network interface the printer is accessed through. So don't use IP-based URIs on systems with lots of network interfaces, or where interfaces appear and disappear all the time. It's giving chaos. π
This mode could also be useful for development and debugging.
Prefer IPv4 or IPv6 specifically in your URIs? Set IPBasedDeviceURIs to "IPv4" for only IPv4 IP addresses, or to "IPv6" for only IPv6 IP addresses.
IPBasedDeviceURIs No
IPBasedDeviceURIs Yes
IPBasedDeviceURIs IPv4
IPBasedDeviceURIs IPv6
CreateRemoteRawPrinterQueues set to "Yes" lets cups-browsed also create local queues pointing to remote raw CUPS queues. Normally only queues pointing to remote queues with a PPD/driver get created, because we don't use drivers on the client side β but sometimes accessing a remote raw queue just makes sense, like if the queue forwards jobs through a special backend such as Tea4CUPS.
CreateRemoteRawPrinterQueues Yes
By default cups-browsed creates local print queues for every shared CUPS print queue it discovers on remote machines in the local network(s). Set CreateRemoteCUPSPrinterQueues to "No" if you don't want that. For example, you can make cups-browsed only create queues for IPP network printers by setting CreateIPPPrinterQueues to anything other than "No" and CreateRemoteCUPSPrinterQueues to "No".
CreateRemoteCUPSPrinterQueues No
Okay, CreateIPPPrinterQueues β this one has a whole menu, so let's go:
"All"β cups-browsed discovers IPP network printers (native printers, not CUPS queues) with known page description languages (PWG Raster, PDF, PostScript, PCL XL, PCL 5c/e) in the local network, and auto-creates print queues for them."Everywhere"β discovers IPP Everywhere printers in the local network (native printers, not CUPS queues) and auto-creates print queues for them."AppleRaster"β discovers Apple Raster printers in the local network (native printers, not CUPS queues) and auto-creates print queues for them."Driverless"β discovers printers designed for driverless use (currently IPP Everywhere and Apple Raster) in the local network (native printers, not CUPS queues) and auto-creates print queues for them."LocalOnly"β auto-creates print queues only for local printers made available as IPP printers. Think IPP-over-USB printers, made available viaippusbxd(8). This is the default."No"β no auto-creating print queues for IPP network printers at all. π
The PPDs are auto-generated by cups-browsed based on properties of the printer polled via IPP. If info is missing, the Bonjour record is used as a last resort for the default values.
This functionality is primarily for mobile devices running CUPS, so they don't need a printer setup tool or a collection of printer drivers and PPDs. Iconic, honestly.
CreateIPPPrinterQueues No
CreateIPPPrinterQueues LocalOnly
CreateIPPPrinterQueues Everywhere
CreateIPPPrinterQueues AppleRaster
CreateIPPPrinterQueues Everywhere AppleRaster
CreateIPPPrinterQueues Driverless
CreateIPPPrinterQueues All
NewIPPPrinterQueuesShared decides whether a print queue for a newly discovered IPP network printer (again, not a remote CUPS queue) gets shared to the local network. This is only valid for newly discovered printers β for printers discovered in an earlier cups-browsed session, cups-browsed remembers whether the printer was shared, so your changes as a user get conserved. Default is not sharing newly discovered IPP printers.
NewIPPPrinterQueuesShared Yes
So how do we handle the print queues cups-browsed creates when cups-browsed shuts down? π
"KeepGeneratedQueuesOnShutdown No" makes the queues get removed. Which makes sense, because these queues only work while cups-browsed is running. cups-browsed has to determine which member printer of a cluster to pass the job on to.
okay so "KeepGeneratedQueuesOnShutdown Yes" is the default, and what it does is literally justβ¦ not delete the queues. That's it, that's the whole vibe. π«Ά And honestly? It's the recommended setting if your cups-browsed is a permanent resident β like, it runs 24/7 and only dips out for short lil' breaks (log rotation, bestie, that's the moment) or when the whole system shuts down. Why tho? Because it dodges the re-creation of all the queues when cups-browsed gets restarted, and that re-creation is exactly the thing that causes a clutter of CUPS notifications all over your desktop. π Nobody wants that notification storm fr fr.
KeepGeneratedQueuesOnShutdown No
Now, AutoClustering time, and this one's lowkey iconic. π
If there's more than one remote CUPS printer whose local queue would end up with the same name, and AutoClustering is set to "Yes" (which, yes, is the default), then only one local queue gets created β and that queue is a whole load-balancing cluster of all the remote printers that would've gotten that name. It's an implicit class, iykyk. So when a bunch of jobs get sent to that queue, they get distributed between the printers using whatever method the LoadBalancing directive picked. π
But here's the tea, bestie: whether clusters form at all depends on the naming scheme for the local queues cups-browsed creates. Let me break it down:
- If you set
LocalQueueNamingRemoteCUPSto"DNSSD"β no automatic clustering for you, sorry, because DNS-SD service names are always unique. π - If you set it to
"RemoteName"β local queues are named exactly how the CUPS queues on the remote servers are named, so equally named queues on different servers do get clustered. (This is literally how CUPS did it back in version 1.5.x or older, vintage behavior β¨) - If you set it to
"MakeModel"β remote printers of the same model get clustered together. Note that a cluster can then contain more than one queue of the same server. Wild, but okay.
And with AutoClustering set to "No", every single remote CUPS printer gets its own individual local queue. To avoid name clashes when you're using the LocalQueueNamingRemoteCUPS settings "RemoteName" or "MakeModel", "@<server name>" gets tacked onto the local queue name. π
π¨ Important caveat: only remote CUPS printers get clustered. IPP network printers and IPP-over-USB printers do not. Not them. Never them.
AutoClustering Yes
AutoClustering No
So cluster formation can also be done manually, if you're the kind of person who needs to control everything (respect π«‘). You do it with the Cluster directive:
Cluster <QUEUENAME>: <EXPRESSION1> <EXPRESSION2> ...
Cluster <QUEUENAME>
If you don't hand it any expressions, then <QUEUENAME> is used as the first and only expression for that cluster. Simple as.
Here's how the matching goes down: discovered printers get matched against all the expressions of all the defined clusters, and the first expression that matches decides which cluster the printer belongs to. Which means β and this is the key part β a printer can only ever belong to one cluster. Once it's matched, the other cluster definitions don't even get checked. No take-backs, periodt. π
The first printer that matches a cluster's expression gets a local queue created with the name <QUEUENAME>. If more printers get discovered and match that same cluster, they join the cluster. Printing to that queue prints to all those printers in a load-balancing way, according to whatever the LoadBalancing directive says. πΈ
Every expression has to be a string of characters with no spaces. If you need spaces, swap them for underscores ('_'). That's the rule, don't fight it.
An expression can be matched in three ways:
- By the name of the CUPS queue on the remote server
- By make and model name of the remote printer
- By the DNS-SD service name of the remote printer
And note: the matching is case-insensitively done, and any group of non-alphanumerical characters gets replaced by a single underscore. β¨
So if your expression is "HP_DeskJet_2540" and the remote server reports "hp Deskjet-2540", the printer gets matched to that cluster. Slay. π¦
If "AutoClustering" is not set to "No", then both your manual cluster definitions and the automatic clustering of equally-named remote queues happen. And if a printer matches in both categories? The match to the manually defined cluster wins, priority baby. π Also, automatic clustering of equally-named remote printers does not happen if there's already a manually defined cluster with that name (at least as long as the printers don't match that cluster).
Examples, bestie, get in: π
To cluster all remote CUPS queues named "laserprinter" in your local network but not cluster any other equally-named remote CUPS printers β your local queue will get named "laserprinter":
AutoClustering No
Cluster laserprinter
To cluster all remote CUPS queues of HP LaserJet 4050 printers into a local queue named "LJ4050":
Cluster LJ4050: HP_LaserJet_4050
And since DNS-SD service names are unique in a network, you can build a cluster out of exactly specified printers (with the spaces replaced by underscores, remember):
Cluster hrdep: oldlaser_@_hr-server1 newlaser_@_hr-server2
Now the LoadBalancing directive, which switches between the two methods of handling load balancing between equally-named remote queues that are all represented by one local print queue making up a cluster of them (that's the implicit class again, keep up π).
The two methods are:
Queuing of jobs on the client β LoadBalancing QueueOnClient:
Here we queue up the jobs on the client and regularly check the clustered remote print queues. If we find an idle queue, we pass a job to it. This is also the method CUPS uses for classes. The advantage is a more even distribution of the job workload on the servers (especially when the printing speed of the servers is very different), and if a server fails, there aren't several jobs stuck or lost. π«Ά The disadvantage? If you take the client (laptop, mobile phone, whatever) out of the local network, printing stops with all the jobs justβ¦ sitting there waiting in the local queue. π
Queuing of jobs on the servers β LoadBalancing QueueOnServers:
Here we check the number of jobs on each of the clustered remote printers and send an incoming job immediately to the remote printer with the lowest amount of jobs in its queue. This way no jobs queue up locally β all the waiting jobs are waiting on one of the remote servers. Not having jobs waiting locally has the advantage that we can take the local machine off the network and all the jobs still get printed. π The disadvantage is that if a server with a full queue of jobs goes away, the jobs go away too. π
Default is queuing the jobs on the client, because that's what CUPS does with classes. β¨
LoadBalancing QueueOnClient
LoadBalancing QueueOnServers
The DefaultOptions directive lets you define one or more option settings that get applied to every print queue newly created by cups-browsed. You supply each option the same way you'd supply options with the "-o" command line argument to the "lpadmin" command (run man lpadmin for more details, bestie, go read it π). You can supply more than one option by separating them with spaces. And by default, no option settings are pre-defined. π
β οΈ Heads up: print queues that cups-browsed already created before remember their previous settings, so these settings do not get applied to them. New queues only. π
DefaultOptions Option1=Value1 Option2=Value2 Option3 noOption4
The AutoShutdown directive specifies whether cups-browsed should automatically terminate when it has no local raw queues set up pointing to any discovered remote printers, or no jobs on such queues β depending on the AutoShutdownOn setting (this is the auto shutdown mode, keep up π«Ά). Setting it to "On" activates auto-shutdown mode, setting it to "Off" deactivates it (that's the default). And then there's the special mode "avahi" β that turns auto shutdown off while avahi-daemon is running and on when avahi-daemon stops. This lets you run cups-browsed on-demand when avahi-daemon is run on-demand. Iconic behavior honestly. π
AutoShutdown Off
AutoShutdown On
AutoShutdown avahi
The AutoShutdownOn directive determines what event cups-browsed considers as inactivity in auto shutdown mode. "NoQueues" (the default) means auto shutdown kicks in when there are no queues for discovered remote printers generated by cups-browsed any more. "NoJobs" means all the queues generated by cups-browsed are without jobs. β¨
AutoShutdownOn NoQueues
AutoShutdownOn NoJobs
DebugLogFileSize defines the maximum size possible (in KBytes) of the log files (cups-browsed_log and cups-browsed_previous_logs) that get created when cups-browsed is running in debugging mode. Set its value to 0 and you turn off any restriction on the size of the file. YOLO, no cap. π
DebugLogFileSize 300
The AutoShutdownTimeout directive specifies after how many seconds without local raw queues set up pointing to any discovered remote printers, or jobs on these queues, cups-browsed should actually shut down in auto shutdown mode. Default is 30 seconds, and 0 means immediate shutdown. π΄
AutoShutdownTimeout 20
NotifLeaseDuration defines how long the D-BUS subscription created by cups-browsed in cupsd will last before cupsd cancels it. The default value is 1 day in seconds β 86400. The subscription renewal is set to happen after half of NotifLeaseDuration has passed. These D-BUS notifications are used for watching over queues and doing specific actions when a D-BUS notification comes in. πΈ
NotifLeaseDuration 86400
FrequentNetifUpdate turns on/off the network interface update routines which happen for each found entry β and those can slow up cups-browsed significantly if you're on a network with many shared printers, or if you use BrowsePoll to a server with many queues. π Note that network interface updates after receiving a D-BUS notification from NetworkManager won't be turned off with this directive. The default value is 'Yes'.
FrequentNetifUpdate Yes
π SEE ALSO π
cups-browsed(8)/usr/share/doc/cups-browsed/README.gz
π AUTHOR π
The authors of cups-browsed are listed in /usr/share/doc/cups-browsed/AUTHORS. π
This manual page was written for the Debian Project, but it may be used by others. Sharing is caring, bestie. π«Ά
and that's a wrap on cups-browsed.conf(5), babes β¨ this lil' glow-up is dated 29 June 2013 and lives in the cups-browsed.conf(5) section of the manual β go forth and configure your printers, you absolute icon π ππ¦
π¦ where this page comes from
- ubuntu noble: cups-browsed 2.0.0-0ubuntu10.2 Β· Apache-2.0-with-GPL2-LGPL2-Exception
- ubuntu noble: cups-browsed 2.0.0-0ubuntu10.3 Β· Apache-2.0-with-GPL2-LGPL2-Exception
- ubuntu questing: cups-browsed 2.1.1-0ubuntu2
- ubuntu resolute: cups-browsed 2.1.1-0ubuntu3 Β· Apache-2.0-with-GPL2-LGPL2-Exception
- ubuntu stonking: cups-browsed 2.1.1-0ubuntu3 Β· Apache-2.0-with-GPL2-LGPL2-Exception
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms