CUPS web interface stops responding after a while

Status changed to 'Confirmed' because the bug affects multiple users.

I have exactly the same thing on 16.04 LTS with the minimal virtual machine install. I run the whole thing on ESXi 5.5 something.
Status:

root@printserver:/var/log/cups# service cups status
● cups.service - CUPS Scheduler
   Loaded: loaded (/lib/systemd/system/cups.service; enabled; vendor preset: ena
   Active: inactive (dead) since Wed 2016-08-24 22:44:57 EEST; 12min ago
     Docs: man:cupsd(8)
  Process: 2177 ExecStart=/usr/sbin/cupsd -l (code=exited, status=0/SUCCESS)
 Main PID: 2177 (code=exited, status=0/SUCCESS)

Aug 24 22:38:23 printserver systemd[1]: Started CUPS Scheduler.

No mention of any abnormalities in any logs whatsoever. I'm afraid I need to go back to 14.04 LTS for this virtual machine.

Please follow the instructions of the section "CUPS error_log" on https://wiki.ubuntu.com/DebuggingPrintingProblems. Thanks.

The same for me:

● cups.service - CUPS Scheduler
   Loaded: loaded (/lib/systemd/system/cups.service; enabled; vendor preset: ena
   Active: inactive (dead) since Di 2016-08-30 08:42:33 CEST; 34min ago
     Docs: man:cupsd(8)
  Process: 11682 ExecStart=/usr/sbin/cupsd -l (code=exited, status=0/SUCCESS)
 Main PID: 11682 (code=exited, status=0/SUCCESS)

error_log attached. Nothing special in there. cups is just going inactive and doesn't come back. A 'sudo service cups restart' fixes the problem until the next reboot:

● cups.service - CUPS Scheduler
   Loaded: loaded (/lib/systemd/system/cups.service; enabled; vendor preset: ena
   Active: active (running) since Di 2016-08-30 09:19:19 CEST; 2min 26s ago
     Docs: man:cupsd(8)
 Main PID: 17018 (cupsd)
   CGroup: /system.slice/cups.service
           ├─17018 /usr/sbin/cupsd -l
           └─17025 /usr/lib/cups/notifier/dbus dbus://

A little correction: 'sudo service cups restart' only solves the problem for a short time, not necessarily till the next reboot.

This seems to be a some kind of desktop/laptop power/resource saving feature that does not take Web UI to the account. CUPS will immediately start up again if I open the printing dialog or something.

When I read Stephan's error log as well as my own, it reads:

"I [30/Aug/2016:08:42:33 +0200] Printer sharing is off and there are no jobs pending, will restart on demand.
I [30/Aug/2016:08:42:33 +0200] Scheduler shutting down normally."

Maybe some kind of xinetd setup would make it possible to shut CUPS down but start it up when one tries to access the web UI.

Please do not expire this bug, that is not a solution. and Stephan has provided the requested error log. WONTFIX would be a better solution if this is the way it is intended to work.

I posted an upstream feature request now to improve the web interface for CUPS running on-demand. See https://github.com/apple/cups/issues/4874.

First, xinetd is not needed. systemd handles running services on-demand well.

Important to know is that there are two access methods for CUPS:

1. The domain socket file /var/run/cups/cups.sock

2. IP Port 631

CUPS can be configured to use one of these methods or both.

Both methods can be used and the applications printing via CUPS and correctly implemented (usually using libcups) automatically choose a suitable method.

As web browsers can only access network locations, the CUPS web interface is only available via port 631, for example under the URI http://localhost:631/. This means that a CUPS only configured for the domain socket cannot use the web interface at all.

When I look at the systemd files which describe how to automatically start CUPS, I see only a /lib/systemd/system/cups.socket which starts CUPS by traffic on the domain socket and /lib/systemd/system/cups.service which starts CUPS on boot. I do not see some systemd instruction file making CUPS triggered via port 631. This seems to be the problem.

By the way, Mike Sweet, author of CUPS, tells that the web interface should work with on-demand CUPS daemon. See https://github.com/apple/cups/issues/4874.

I tried now the following:

till@till-x1carbon:~/printing/cups/bzr/y$ sudo systemctl stop cups
Warning: Stopping cups.service, but it can still be activated by:
  cups.socket
  cups.path
till@till-x1carbon:~/printing/cups/bzr/y$ ps auxwww | grep cupsd
till 4265 0.0 0.0 14224 896 pts/19 S+ 23:33 0:00 grep --color=auto cupsd

Accessed http://localhost:631/ in web browser --> FAILED.

till@till-x1carbon:~/printing/cups/bzr/y$ lpstat -r
scheduler is running

Accessed http://localhost:631/ in web browser --> SUCCEEDED (the "lpstat -r" triggered cupsd by
                                                             domain socket)

till@till-x1carbon:~/printing/cups/bzr/y$ ps auxwww | grep cupsd
root 4290 1.4 0.1 169908 10260 ? Ssl 23:33 0:00 /usr/sbin/cupsd -l
till 4311 0.0 0.0 14224 1056 pts/19 S+ 23:33 0:00 grep --color=auto cupsd
till@till-x1carbon:~/printing/cups/bzr/y$

So for the web interface we need some systemd unit file which triggers CUPS via port 631. Any example files welcome.

Nice to see some progress, but the initial problem description and mine is different from what has been discovered. The problem is not just the webinterface, it is cups itself (or the scheduler) which goes inactive and doesn't come back.

Today I was able to invest more time. On my system there was still a client.conf in /etc/cups/ The man page says it is deprecated. I moved it to client.conf_bak and restarted cups. The scheduler is now running for over 3 hours. I will have an eye on this, but maybe this fixed my cups problem.

I have done some tests and have found a solution. Please try it out.

Edit the file (with sudo):

/lib/systemd/system/cups.socket

adding a line

ListenStream=631

in the "[Socket]" section. The file should look like this then:

----------
[Unit]
Description=CUPS Scheduler

[Socket]
ListenStream=/var/run/cups/cups.sock
ListenStream=631

[Install]
WantedBy=sockets.target
----------

Now make sure that this does not produce any editor backup files, like /lib/systemd/system/cups.socket~ or /lib/systemd/system/cups.socket.backup. Remove such files now.

Now restart systemd with the command

sudo systemctl daemon-reload

Now systemd does not only restart CUPS via the domain socket but also via port 631, meaning that it also gets started when trying to access via the web interface (or any other application which accesses only via port 631).

Please try it out.

If you do not want to wait everytime until CUPS stops by itself for doing the tests, you can stop it with

sudo systemctl stop cups

What was in your /etc/cups/client.conf (now /etc/cups/client.conf_bak)? If it pointed to a CUPS on a remote machine, all your CUPS access (from applications/command line, not web interface) was directed to the remote machine with a different CUPS setup. Now you are using always the CUPS on your local machine.

Note that client.conf is deprecated but still working as originally intended (and so often an admin's nightmare).

hi Till,
there is no client.* in /etc/cups

edited /lib/systemd/system/cups.socket

restarted systemd and cups.

waiting for the bug to come back ...

in my /etc/cups/client.conf (now /etc/cups/client.conf_bak) are two lines:
ServerName NameoftheremoteCUPSServer
ServerName localhost

The remote CUPS Server is running Version 1.5.3 and my client 2.0.2.

Not having "ListenStream=631" in the systemd cups.socket file is intended. See the answer from Mike Sweet, author of CUPS:

----------
First, the reason why we don't include "ListenStream=631" is because that exposes cupsd to remote attack. And we don't listen on localhost (which has a similar security issue) because it causes problems when binding to the "any" address on Linux.

Second, once cupsd starts it will create the localhost (or "any" address) listener for you, and stay running indefinitely. And cupsd uses a KeepAlive file to tell systemd to start it up on bootup once you enable the web interface, so it should be running right away unless you've added something to manually start/stop cupsd.
----------

In Yakkety (16.10), CUPS behaves as intended upstream, not automatically shutting down when it shares at least one printer or the web interface is active (turned on via "WebInterface Yes" in cupsd.conf). So there this bug should be fixed.

In earlier Ubuntu versions, like Xenial (16.04 LTS), there is a patch which allows for CUPS auto shutdown due to another problem, whgich is fixed in later CUPS versions. This fix needs to get backported so that auto shutdown can be suppressed with active web interface, to match the upstream standard.

SRU fix for Xenial is simple. In the CUPS 2.1.3 used there the upstream bug (https://github.com/apple/cups/issues/4755) is already fixed but it seems that the removal of the workaround patch (auto-shutdown-on-idle-also-with-webinterface-on.patch) got forgotten. So removing this patch seems to be everything which has to get done here.

I had the same problem in Ubuntu 16.04.1. After some testing I removed all (3) printers and all cups-related packages and reinstalled them. And now (without any additonal changes) all works fine. The only difference: The first time I used a port forwarding to the remote print server like "ssh -L 1631:127.0.0.1:632 someuser@somehost" and a local URl "127.0.0.1:1631" (because i worked as an unpriviliged user and have a local CUPS daemon on 631). At some cups-Admin-Pages there where error pages like "You have to use 127.0.0.1:631...". The second time i stopped my local cupsd and called "ssh -L 631:127.0.0.1:631 someuser@somehost" as privileged user.

No. Seems to be the option "-l" which causes systemd to shutdown cupsd and to restart if a print job is available. For applications with pre-checks for available printers or given printer names (for instance with java javax.print.PrintServiceLookup) or with CUPS web Interface on demand this does not work. I changed the option "-l" to "-f" in /lib/systemd/system/cups.service.

Fixed package uploaded to xenial-proposed. Please test the package as soon as it gets available and appropriate test instructions will get posted here. Your feedback is needed in order to make the fix an official update for Xenial.

SRU team: debdiff attached.

Hello dominix, or anyone else affected,

Accepted cups into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/cups/2.1.3-4ubuntu0.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Note that bug 1642966 which many people observed when updating is not caused by the changes of this SRU (small patch removed from CUPS daemon). So do not worry and apply the workaround shown there, should you also run into a problem with the update. Once your installed CUPS packages being 2.1.3-4ubuntu0.1 please test whether this bug (CUPS web interface stops responding) is fixed. Thank you.

I want to remind everyone subscribed to this bug to please test the fixed package and verify it.

If you get an error during the installation process (see bug 1642966), please run the commands

sudo service cups stop
sudo apt-get install -f
sudo service cups start

in a terminal window to complete the installation (see also comment #5 in bug 1642966). Then test whether this bug is fixed.

To the SRU team: Bug 1642966 cannot be caused by the fix for this bug. The fix is a trivial change in the scheduler, see the debdiff attched to comment #20 of this bug. Bug 1642966 is probably caused by some coincidence which had also broken any other update of the cups package.

fix is on the way. Till now it has not been solved. I am running last 2.1.3-4ubuntu0.1 cups.

I will soon known if it fix the problem. thanks.

it looks good to me, there is 24h on service with no stop on the interfaces.

dominix, thanks. I have marked the SRU as verified now.

> To the SRU team: Bug 1642966 cannot be caused by the fix for this bug.

I agree. But nevertheless, users may still get errors when upgrading, and won't get errors if we don't release this SRU. So the failures would still be a consequence of releasing this SRU, so I think we should care.

> Bug 1642966 is probably caused by some coincidence which had also broken any other update of the cups package.

Agreed. I did some investigation, and I think it's a race. I added some details in that bug.

So the question is: do we release this SRU in the knowledge that it will cause failures for some users (quite a large number given the numbers affected in bug 1642966), or do we defer until we can have a fix for that bug too?

How important is it that this SRU lands sooner, rather than waiting and bundling a fix for bug 1642966 at the same time?

Another consideration is that the web interface is optional, whereas the failure in bug 1642966 will happen for some proportion of users with a default installation.

To be clear, I'm not saying that we shouldn't release this SRU; just that some consideration and discussion is warranted to consider the trade-off in both directions.

Hi!
I have same problem.
Ubuntu 16.04.1.
When login in localhost:631, to work with printer's, after some minutes, cups go down, and i see with sudo service cups status, he is inactive.
Problem occur only when logged on web interface, else no.

To give more information on this issue. We are heavily using cups lpd daemon (via inetd) because the machine is used to convert from some old systems, old fashioned printer that do not exists no more, and cups is able to convert this in whatever we want (pcl, pdf, postscript) via its powerfull drivers plugins system.
So cups.lpd might be involved in this issue, because we dont have this issue on system that do not run cups.lpd

For those affected, you can install the version in proposed for the time being (see comment 21), until we decide how to manage this (see comment 27). As I understand it, this is the exact fix that will eventually land in updates.

Thank you Robie for pointing to the fix in comment 21 and for the comment that the final fix should be exactly as that one. Any estimate about when will we see the final fix in updates?

Please note that the delay of publishing the SRU for this bug is cause by bug 1642966. We either need to put out the SRU for that bug first (as it blocks any installation of the CUPS packages) or put out a joint SRU for both bugs.

> ** Changed in: cups (Ubuntu Xenial)
> Status: Fix Committed => Fix Released

No, it's not.

This is still showing up as ready in the pending-sru report, and I'd like it not to in order to prevent accidents. So I'm removing the verification-done tag for now. Please re-add it when this needs reconsidering. It may need re-verifying if we superseded the package in -proposed anyway.

Same problem affects my installation of Xubuntu-16.04.1 64bit system.
I have enabled proposed and updated all the many cups packages in that repository and then disabled proposed again.
I think this has solved my problem of cups stopping running but will have to report back after running for some period of time.

An update to my post #36.

I can now confirm that the problem is solved for me; cups no longer stops running after a few minutes, and once again I am able to access ,localhost:631 without the need to start cups running again.

ajgreeny, thank you for testing.

Please see comments 33 and 35. Any progress on that bug?

This is a very serious bug that breaks network printing in certain configurations. To be clear: its not just that cups stops and the web interface is unavailable - it can lead to not being able to print as the print server looks like it is offline to the clients:

D [09/Feb/2017:10:07:02 -0600] [Job 12] Connection error: Transport endpoint is not connected
E [09/Feb/2017:10:07:02 -0600] [Job 12] The printer is not responding.

I was running into this issue on some print servers but not others and in comparing the two cupsd.conf files I found out I can prevent the issue by changing
BrowseLocalProtocols CUPS
to
BrowseLocalProtocols dnssd

The real problem here is that a feature like this should have a clear and easy way to turn if off completely. I don't ever want cups on a print server stopping to save an insignificant amount of cpu cycles or memory or electricity!

Applying the packages from xenial-proposed does fix it for me, but in my opinion this is a pretty serious issue that needs a quicker fix.

I think the best fix at the moment is the suggestion from Andreas Krausz (kukorica) to change " the option "-l" to "-f" in /lib/systemd/system/cups.service." as it seems that is the only way to turn off this "feature".

launchpad-groovix: Weird. This "feature" shouldn't be active at all when printer sharing is enabled. Did you look the cups log to make sure that it really is the same problem?

And yes, this is a serious issue, but if you read the earlier messages, you see that the fix will cause the bug 1642966 that will result the breakage of some systems. This really should have been fixed before the release of 16.04 xenial (or the patch that caused this maybe shouldn't have been written in first place since it AFAIK solved a thing that was not really a problem), but it's now too late to do anything to the fact that it was not and it's now difficult to fix it since breakage of systems that have a LTS release installed should be avoided.

(iiro) "Did you look the cups log to make sure that it really is the same problem?"

Without any fixes I get these messages about 2 minutes after restarting cups and cupsd is no longer running:

I [09/Feb/2017:04:08:47 -0600] Printer sharing is off and there are no jobs pending, will restart on demand.
I [09/Feb/2017:04:08:47 -0600] Scheduler shutting down normally.

After installing the proposed updates or switching to BrowseLocalProtocols dnssd those messages go away and cupsd stays running and client print jobs don't fail with "Connection error: Transport endpoint is not connected."

(iiro) "but it's now too late to do anything"
Assuming there is absolutely no way to fix bug 1642966, why not switch "-l" to "-f" in /lib/systemd/system/cups.service as an official fix? Is that the only way to completely disable this buggy feature?

launchpad-groovix: I meant it's too late to do anything about that this bug slipped into xenial in first place. Fixing the problem afterwards however should be possible, if little more complicated, sorry for being unclear. The #1642966 probably is fixable and there has been effort to do that to the point there is a PPA that's supposed to contain the fix. However, efforts to make it an official SRU seem to have been stalled for since a month.

I'm also affected by this bug, lots of shared printers (this is the cups server for the network) and cupsd shutting down claiming printer sharing was off.

launchpad-groovix: in 14.04, the only allowed values for BrowseLocalProtocol are All and dnssd, in 16.04 I see All, dnssd, and none. Is CUPS some deprecated setting? My cupsd.conf does not have this set at all, so it's using the default whatever that is.

I'm also affected by this bug, lots of shared printers (this is the cups server for the network) and cupsd shutting down claiming printer sharing was off.

launchpad-groovix: in 14.04, the only allowed values for BrowseLocalProtocol are All and dnssd, in 16.04 I see All, dnssd, and none. Is CUPS some deprecated setting? My cupsd.conf does not have this set at all, so it's using the default whatever that is.

Adding BrowseLocalProtocol dnssd to cupsd.conf did not solve the problem for me, btw.

Switching "-l" to "-f" in /lib/systemd/system/cups.service solved the problem for me. cupsd has now been up for about an hour without shutting down automatically.

Johannes Martin (johannes-martin) wrote: Is CUPS some deprecated setting?

Yes - "BrowseLocalProtocols CUPS" was valid in 12.04 ( what I upgraded from ) but not anymore. If you needed to add a BrowseLocalProtocols line as opposed to switching its value, it seems that this auto-shutdown feature is triggering off that option being present and assigned certain values.

I've let the new version of cups which fixes bug 1642966, into the -proposed pocket for Xenial. My thought was that people would be upgrading from 2.1.3-4 to 2.1.3-4ubuntu0.2 which contains the fix for both bugs.

The -proposed 2.1.3-4buntu0.2 fixes this issue for me.

Bug 1642966 has an upload in xenial-proposed, so we can resume treating this issue as verification-done.

Unfortunately we still have bug 1642966 which wasn't fixed in 2.1.3-4buntu0.2 as expected, and had to be deleted (see bug 1676380). So this problem still remains. Though we have a fix, we unfortunately can't deploy it without a fix for bug 1642966, since releasing such a fix will cause user errors.

I just ran into this bug today when I went to use the official cups package for the first time. Or at least I'm pretty sure I did. Google landed me here when I went to search for the output of "service cups status", of which my test system's output looks very similar to the output of the person who opened this ticket and the described behavior is identical to what I'm running into.

This bug makes the cups package for Ubuntu useless for initial configuration from the comfort of a standard desktop - a common enough scenario, IMO. I just can't believe it's taken almost 9 months to still not have a fix pushed out everywhere, but there you have it. Directly running the command being run by the system service (/usr/sbin/cupsd -l) has identical behavior - the software self-terminates after a few minutes of inactivity.

I'm testing the -f option and I'm hoping that it will resolve the issue for me.

As it's coming up to the first anniversary of the bug, I thought I would mention that I too have run into it. I normally use Ubuntu 12.04 but I'm trying out Ubuntu 16.04, so my first reaction was that the user interface for CUPS must have changed.

However I got pointed to this page and succeeded with the above mentioned fix of changing line
"ExecStart=/usr/bin/cupsd -l"
to
"ExecStart=/usr/bin/cupsd -f"
in /lib/systemd/system/cups.service
and then
"systemctl daemon-reload"

Hi,

Is there any updated to this bug ?

Thanks.

As part of a recent change in the Stable Release Update verification policy we would like to inform that for a bug to be considered verified for a given release a verification-done-$RELEASE tag needs to be added to the bug where $RELEASE is the name of the series the package that was tested (e.g. verification-done-xenial). Please note that the global 'verification-done' tag can no longer be used for this purpose.

Thank you!

It took me a day to find out why our Java App stop printing after a while and cupsd is gone without a notification at all. Could please someone explain why the "cupsd -l" should be useful at all?

Thanks

Hello dominix, or anyone else affected,

Accepted cups into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/cups/2.1.3-4ubuntu0.3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed.Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-xenial to verification-done-xenial. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-xenial. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

This morning at about 10:30 UTC I updated to cups-2.1.3-4ubuntu0.3 on my 64bit Xubuntu-16.04 using kernel 4.4.0-92 and it has so far not stopped running.
My /etc/cups/cupsd.conf has the "WebInterface Yes" entry but so far no problems at all, though I had no problems with the cups-2.1.3-4ubuntu0.2 version either to which I upgradede with a comment on January 26th.

ajgreeny, so it seems that it is fixed for you now. Marking this as verified.

This bug was fixed in the package cups - 2.1.3-4ubuntu0.3

---------------
cups (2.1.3-4ubuntu0.3) xenial; urgency=high

  * Adding maintainer script debian/cups-daemon.prerm to deal with situations
    where "old-version" (installed package) prerm script fails. (LP: #1642966).

cups (2.1.3-4ubuntu0.2) xenial; urgency=medium

  * Make cups.path unit be part of the cups.service, since cups.path
    should stop if and when cups.service is stopped. LP: #1642966

cups (2.1.3-4ubuntu0.1) xenial-proposed; urgency=medium

  * Removed auto-shutdown-on-idle-also-with-webinterface-on.patch
    as it causes CUPS to auto-shutdown when web interface support is
    active (LP: #1598300).

 -- Eric Desrochers <email address hidden> Fri, 18 Aug 2017 12:08:28 -0400

The verification of the Stable Release Update for cups has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regressions.

I am on Kubuntu 17.10 and I am suffering this bug. I do not have the web interface enabled but I have an IPP printer. I have attached the cupsd.conf on my system.
I think this is the relevant part of the file:

# Only listen for connections from the local machine.
Listen localhost:631
Listen /var/run/cups/cups.sock

# Show shared printers on the local network.
Browsing Off
BrowseLocalProtocols dnssd

I attach the error_log file with debug logging mode. The CUPS notifier closes after a while. That might be the problem. When I open the KDE printer dialog, the D-BUS system bus dumps these messages calling the Notifier method. Opening the printing dialog from LibreOffice writer does not print anything, not even in the session bus:

method call time=1520971612.523540 sender=:1.364 -> destination=org.freedesktop.DBus serial=1 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=Hello
method return time=1520971612.523567 sender=org.freedesktop.DBus -> destination=:1.364 serial=1 reply_serial=1
   string ":1.364"
signal time=1520971612.523580 sender=org.freedesktop.DBus -> destination=(null destination) serial=19 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameOwnerChanged
   string ":1.364"
   string ""
   string ":1.364"
signal time=1520971612.523598 sender=org.freedesktop.DBus -> destination=:1.364 serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=NameAcquired
   string ":1.364"
method call time=1520971612.524056 sender=:1.364 -> destination=org.freedesktop.DBus serial=2 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string "type='signal',path='/org/cups/cupsd/Notifier',interface='org.cups.cupsd.Notifier',member='ServerStarted'"
method call time=1520971612.524213 sender=:1.364 -> destination=org.freedesktop.DBus serial=3 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string "type='signal',path='/org/cups/cupsd/Notifier',interface='org.cups.cupsd.Notifier',member='ServerStopped'"
method call time=1520971612.524295 sender=:1.364 -> destination=org.freedesktop.DBus serial=4 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string "type='signal',path='/org/cups/cupsd/Notifier',interface='org.cups.cupsd.Notifier',member='ServerRestarted'"
method call time=1520971612.524399 sender=:1.364 -> destination=org.freedesktop.DBus serial=5 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string "type='signal',path='/org/cups/cupsd/Notifier',interface='org.cups.cupsd.Notifier',member='ServerAudit'"
method call time=1520971612.524514 sender=:1.364 -> destination=org.freedesktop.DBus serial=6 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string "type='signal',path='/org/cups/cupsd/Notifier',interface='org.cups.cupsd.Notifier',member='PrinterAdded'"
method call time=1520971612.524595 sender=:1.364 -> destination=org.freedesktop.DBus serial=7 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string "type='signal',path='/org/cups/cupsd/Notifier',interface='org.cups.cupsd.Notifier',member='PrinterModified'"
method call time=1520971612.524690 sender=:1.364 -> destination=org.freedesktop.DBus serial=8 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string "type='signal',path='/org/cups/cupsd/Notifier',interface='org.cups.cupsd.Notifier',member='PrinterDeleted'"
method call time=1520971612.524760 sender=:1.364 -> destination=org.freedesktop.DBus serial=9 path=/org/freedesktop/DBus; interface=o...