Bug 1427721 - dbus-daemon goes bonkers and repeatedly spams logs with 'Connection ":1.15" is not allowed to add more match rules'
Summary: dbus-daemon goes bonkers and repeatedly spams logs with 'Connection ":1.15" i...
Keywords:
Status: CLOSED EOL
Alias: None
Product: Fedora
Classification: Fedora
Component: dbus
Version: 28
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
Assignee: Colin Walters
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-03-01 00:53 UTC by Michal Jaegermann
Modified: 2024-12-10 21:23 UTC (History)
21 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2019-05-28 23:02:31 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Michal Jaegermann 2017-03-01 00:53:43 UTC
Description of problem:

Last night on one machine dbus-daemon started spewing over and over:
dbus-daemon[1381]: [session uid=401 pid=1381] Connection ":1.15" is not allowed to add more match rules (increase limits in configuration file if required; max_match_rules_per_connection=50000)

This "very informative" message was repeated with a rate between 30 and 50 times per second in blocks which were appearing every 30 seconds.  No rate limiting, no folding messages with the same content.

It is far from clear what triggered that storm.  The last log entry with the same timestamp as beggining of all that was from 00:32:11 and it said:
cupsd[1636]: REQUEST localhost - - "POST / HTTP/1.1" 200 185 Renew-Subscription successful-ok

Only rebooting the stricken machine some ten hours later restored a normal operation.

Version-Release number of selected component (if applicable):
dbus-1.11.10-1.fc25
systemd-231-14.fc25

How reproducible:
I do not know. Do not recall seeing this earlier and hope not to bump into that again.

Additional info:
This does seem to be different from bug #1396900 as there is no Bluetooth hardware on that system and bluetooth.service is not running.

Comment 1 Michal Jaegermann 2017-03-01 00:56:22 UTC
Sorry, a typo in a bug number from "Additional info:".  This was supposed to be bug #1396800

Comment 2 Michal Jaegermann 2017-03-01 17:23:14 UTC
I am afraid that this message storm from dbus-daemon started again.  It is completely unclear what may have triggered it as a preceding log entry of any kind has a time stamp around 23 minutes earlier.  Moreover going through logs I am finding more such events happening apparently at random.  Only connection identifiers change.  For example ":1.701", ":1.152", ":1.103" and so on although
this time it is ":1.15" again.  It does not look like that there is another way to clear this condition but a complete reboot.

Another weird thing in logs, although I cannot tell if that could possibly have any connection with the problem, are repeating complaints  'unable to create file '/run/user/401/dconf/user': Permission denied.  dconf will not work properly' from tracker-extract while the file /run/user/401/dconf/user definitely does exist with a lenght of 2 (two null bytes inside), permissions '-rw-------' and is owned by a user with an id of 401.

Comment 3 Colin Walters 2017-03-01 17:50:19 UTC
I saw this once too, and used `busctl` to map the leaking unique connection id (e.g. `1:14`) → gnome-shell.

I didn't try debugging it past that.

Comment 4 Michal Jaegermann 2017-03-02 02:42:01 UTC
When looking for "... is not allowed to add more match rules ..." from dbus-daemon I found that it started doing that again and once again in the point when, to my best knowledge, the machine in question was basically idle.

In a "department of weird error messages in vicinity" I found this time the following:

avahi-daemon[8876]: dbus[8876]: D-Bus library appears to be incorrectly set up; failed to read machine uuid: Failed to open "/etc/machine-id": No such file or directory
avahi-daemon[806]: See the manual page for dbus-uuidgen to correct this issue.

The point is that /etc/machine-id definitely does exist and 'dbus-uuidgen --get' does print its content so it is far from clear how one could "correct" that.

Comment 5 Michal Jaegermann 2017-03-04 03:24:14 UTC
(In reply to Colin Walters from comment #3)
> I saw this once too, and used `busctl` to map the leaking unique connection
> id (e.g. `1:14`) → gnome-shell.

I am seeing that all over the place.  Sometimes 'busctl --show' does not list a connection which appears in logs.  Other time it does.  In this moment I have "1.15" again and the corresponding line from busctl listing is:

:1.15                                     1251 polkitd         polkitd          :1.15         polkit.service

but other times, when the connection in question is present, it could be something else.

In this particular case it is easy to do 'systemctl restart polkit.service' and after that polkitd connection comes back as ":1.70" while ":1.15" is not
listed by busctl anymore.  Still log spamming with 'Connection ":1.15" is not allowed to add more match rules' does not stop at all.

This generated gigabytes of junk in my /var/log/journal/ and likely does wonders to my solid-state disk. Sigh!

Comment 6 Michal Jaegermann 2017-03-06 18:20:22 UTC
Smells like gnome-shell together with gvfs-daemon may be behind this issue.  Here is an excerpt from logs after a reboot and where ":1.16" is mentioned:

Mar 04 11:56:48 ... dbus-daemon[1445]: [session uid=401 pid=1445] Activating via systemd: service name='org.gtk.vfs.Daemon' unit='gvfs-daemon.service' requested by ':1.16' (uid=401 pid=1534 comm="/usr/bin/gnome-shell ")
Mar 04 11:56:49 ... dbus-daemon[1445]: [session uid=401 pid=1445] Activating service name='org.gnome.Shell.CalendarServer' requested by ':1.16' (uid=401 pid=1534 comm="/usr/bin/gnome-shell ")
Mar 04 11:56:49 ... dbus-daemon[1445]: [session uid=401 pid=1445] Activating via systemd: service name='org.gtk.vfs.UDisks2VolumeMonitor' unit='gvfs-udisks2-volume-monitor.service' requested by ':1.16' (uid=401 pid=1534 comm="/usr/bin/gnome-shell ")
Mar 04 11:56:49 ... dbus-daemon[1445]: [session uid=401 pid=1445] Activating via systemd: service name='org.gtk.vfs.AfcVolumeMonitor' unit='gvfs-afc-volume-monitor.service' requested by ':1.16' (uid=401 pid=1534 comm="/usr/bin/gnome-shell ")
Mar 04 11:56:51 ... dbus-daemon[1445]: [session uid=401 pid=1445] Activating via systemd: service name='org.gtk.vfs.Metadata' unit='gvfs-metadata.service' requested by ':1.16' (uid=401 pid=1534 comm="/usr/bin/gnome-shell ")
Mar 05 14:44:32 ... dbus-daemon[1445]: [session uid=401 pid=1445] Connection ":1.16" is not allowed to add more match rules (increase limits in configuration file if required; max_match_rules_per_connection=50000)
Mar 05 14:44:32 ... dbus-daemon[1445]: [session uid=401 pid=1445] Connection ":1.16" is not allowed to add more match rules (increase limits in configuration file if required; max_match_rules_per_connection=50000)
Mar 05 14:44:32 ... dbus-daemon[1445]: [session uid=401 pid=1445] Connection ":1.16" is not allowed to add more match rules (increase limits in configuration file if required; max_match_rules_per_connection=50000)
Mar 05 14:44:32 ... dbus-daemon[1445]: [session uid=401 pid=1445] Connection ":1.16" is not allowed to add more match rules (increase limits in configuration file if required; max_match_rules_per_connection=50000)
Mar 05 14:44:32 ... dbus-daemon[1445]: [session uid=401 pid=1445] Connection ":1.16" is not allowed to add more match rules (increase limits in configuration file if required; max_match_rules_per_connection=50000)
.....

and off we go to the races.

Comment 7 Michal Jaegermann 2017-03-28 23:20:39 UTC
Web searches indicate that various instances of the problem of flooding log files, and making them barely useable in effect, are many, many years old and nobody seems to be unduly bothered that this is happening.  Therefore to alleviate the issue I hacked 'dbus-daemon' to complain as above only when unsigned short counter wraps to zero.  Effects of this change in my last experiment are as the following:

Mar 17 11:32:15 ... dbus-daemon[781]: [system] Activating via systemd: service name='org.freedesktop.ColorManager' unit='colord.service' requested by ':1.35' (uid=42 pid=1338 comm="/usr/libexec/gnome-settings-daemon ")
Mar 17 11:32:15 ... dbus-daemon[781]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service' requested by ':1.35' (uid=42 pid=1338 comm="/usr/libexec/gnome-settings-daemon ")
Mar 17 11:32:29 ... dbus-daemon[1453]: [session uid=401 pid=1453] Activating service name='org.gnome.Shell.CalendarServer' requested by ':1.35' (uid=401 pid=1583 comm="gnome-shell --sm-client-id 1036a1527770dbe6a014893")
Mar 17 11:32:31 ... dbus-daemon[1453]: [session uid=401 pid=1453] Activating via systemd: service name='org.gtk.vfs.Metadata' unit='gvfs-metadata.service' requested by ':1.35' (uid=401 pid=1583 comm="gnome-shell --sm-client-id 1036a1527770dbe6a014893
Mar 20 20:04:01 ... dbus-daemon[1453]: [session uid=401 pid=1453] Connection ":1.35" is not allowed to add more match rules (increase limits in configuration file if required; max_match_rules_per_connection=50000)
Mar 24 21:56:45 ... dbus-daemon[1453]: [session uid=401 pid=1453] Connection ":1.76" is not allowed to add more match rules (increase limits in configuration file if required; max_match_rules_per_connection=50000)
Mar 26 13:46:08 ... dbus-daemon[1453]: [session uid=401 pid=1453] Connection ":1.76" is not allowed to add more match rules (increase limits in configuration file if required; max_match_rules_per_connection=50000)
Mar 28 13:21:56 ... dbus-daemon[1453]: [session uid=401 pid=1453] Connection ":1.76" is not allowed to add more match rules (increase limits in configuration file if required; max_match_rules_per_connection=50000)

'Connection ":1.35"' does look like gnome-settings-daemon.  Neither log files nor an output from busctl give any hints what 'Connection ":1.76"' could be.

Apparently reducing a number of writes "...is not allowed to add more match rules..." in logs is further cutting down their number as in a comparison with a situation when I was using an unmodified dbus-daemon these messages start later and show up less frequently.  True, I did not really count a number of these messages but only extrapolated from a few minutes samples and based on this expected to see a substantially
higher rate.  Also the past experience indicated that once 'Connection ":1.35"' would start its "very informative" repetitions it is not going to stop.

BTW - for ":1.35" the corresonding line in an ouput from busctl looks like this:

:1.35                                     1338 gnome-settings- gdm              :1.35         session-c1.scope          c1         -

Comment 8 RobbieTheK 2017-05-19 20:47:51 UTC
I'm seeing the exact same thing after trying to switch from Lightdm back to GDM and I posted more at a possibly related bug: https://bugs.freedesktop.org/show_bug.cgi?id=86442

Comment 9 Michal Jaegermann 2017-09-07 20:41:39 UTC
(In reply to RobbieTheK from comment #8)
> I'm seeing the exact same thing after trying to switch from Lightdm back to
> GDM and I posted more at a possibly related bug:
> https://bugs.freedesktop.org/show_bug.cgi?id=86442

https://bugs.freedesktop.org/show_bug.cgi?id=86442 sports a status RESOLVED FIXED for some time.  My log files are still clobbered with floods of 'dbus-daemon[1177]: [session uid=400 pid=1177] Connection ":1.48" is not allowed to add more match rules (increase limits in configuration file if required; max_match_rules_per_connection=50000)' and similar.  What gives???

Comment 10 Fedora End Of Life 2017-11-16 19:33:04 UTC
This message is a reminder that Fedora 25 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 25. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '25'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 25 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Comment 11 Michal Jaegermann 2017-12-23 16:45:48 UTC
This is from dbus-1.12.0-1.fc27.x86_64 on a machine with kernel-4.14.7-300.fc27.x86_64:

dbus-daemon[1486]: [session uid=401 pid=1486] Connection ":1.43" is not allowed to add more match rules (increase limits in configuration file if required; max_match_rules_per_connection=50000)

In a burst which started this morning journald quickly collected 2412 lines of that sort and for the moment this stopped.  busctl does not show up 'Connection ":1.43"'. There are :1.42 and :1.44 as follows:

1212 gnome-shell     gdm              :1.42         session-c1.scope
1282 wpa_supplicant  root             :1.44         wpa_supplicant.service

So far the only way to alleviate this issue seems to be to hack dbus-daemon and prevent there repeating of these messages.

Comment 12 Michal Jaegermann 2017-12-23 21:00:46 UTC
So far today two temper tantrums were registered.   The first one lasted around 10 minutes and produced 2412 lines in journal like in a comment 11. The second one happened few hours later, lasted around half an hour and added next 5428 lines without really adding any new information.  Both were preceded in journal with:

    .... gnome-shell[1732]: loading default theme ...

Anybody with bright ideas?

Comment 13 Frantisek Sumsal 2018-03-12 12:58:11 UTC
I noticed the same issue few weeks ago:

Mar 12 13:50:53 pyrelight dbus-daemon[1771]: [session uid=1000 pid=1771] Connection ":1.14" is not allowed to add more match rules (increase limits in configuration file if required; max_match_rules_per_connection=50000)

$ busctl | grep 1.14
:1.14                                      1254 sddm            root             :1.14         sddm.service 

$ journalctl --no-pager MESSAGE='[session uid=1000 pid=1771] Connection ":1.14" is not allowed to add more match rules (increase limits in configuration file if required; max_match_rules_per_connection=50000)' | wc -l
134303

$ rpm -q systemd dbus sddm fedora-release
systemd-234-10.git5f8984e.fc27.x86_64
dbus-1.12.0-1.fc27.x86_64
sddm-0.15.0-1.fc27.x86_64
fedora-release-27-1.noarch


After a brief debugging a message appears after each pressed key for some weird reason.

Comment 14 Sami Farin 2018-03-14 12:14:51 UTC
dbus-daemon[7119]: message repeated 18 times: [[session uid=500 pid=7119] Connection ":1.80" is not allowed to add more match rules (increase limits in configuration file if required; max_match_rules_per_connection=50000)]

safari      7119  0.0  0.1  61916 20724 ?        Ss   Mar09   0:05 /usr/bin/dbus-daemon --session --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only

$ dbus-send --system --dest=org.freedesktop.DBus --print-reply /org/freedesktop/DBus org.freedesktop.DBus.GetConnectionCredentials string::1.80
Error org.freedesktop.DBus.Error.NameHasNoOwner: Could not get credentials of name ':1.80': no such name

"busctl monitor" says nothing.

but each time I press A KEY in mate-terminal, I get this:
method call time=1521029535.701579 sender=:1.80 -> destination=org.freedesktop.DBus serial=56235 path=/org/freedesktop/DBus; interface=org.freedesktop.DBus; member=AddMatch
   string "type='signal',interface='ca.desrt.dconf.Writer',path='/ca/desrt/dconf/Writer/user',arg0path='/org/mate/terminal/global/'"
error time=1521029535.701595 sender=org.freedesktop.DBus -> destination=:1.80 error_name=org.freedesktop.DBus.Error.LimitsExceeded reply_serial=56235
   string "Connection ":1.80" is not allowed to add more match rules (increase limits in configuration file if required; max_match_rules_per_connection=50000)"

dbus-monitor does not print those for each key press in gnome-terminal or xterm.

Comment 15 Louis van Dyk 2018-03-23 02:37:50 UTC
I have been plagued with this too for ages!  It makes tail /var/log/messages pointless!

My iteration is:
Mar 23 04:26:15 fedora dbus-daemon[6561]: [session uid=1000 pid=6561] Connection ":1.43" is not allowed to add more match rules (increase limits in configuration file if required; max_match_rules_per_connection=50000)
Mar 23 04:26:15 fedora dbus-daemon[6561]: [session uid=1000 pid=6561] Connection ":1.43" is not allowed to add more match rules (increase limits in configuration file if required; max_match_rules_per_connection=50000)
Mar 23 04:26:15 fedora dbus-daemon[6561]: [session uid=1000 pid=6561] Connection ":1.43" is not allowed to add more match rules (increase limits in configuration file if required; max_match_rules_per_connection=50000)

and so on ...

According to busctl:
NAME                                                       PID PROCESS         USER             CONNECTION    UNIT                      SESSION    DESCRIPTION
:1.43                                                     4114 systemd         gdm              :1.43         user           -          -

where ps ax | grep 4114 shows the line:
 4114 ?        Ss     0:00 /usr/lib/systemd/systemd --user

I am on  Fedora 26.
systemd-233-7.fc26.x86_64
kernel-4.15.10-200.fc26.x86_64

Comment 16 Paweł 2018-05-06 10:55:12 UTC
Same for f28 (mate-terminal)
May 06 11:59:30 corsair.sunwire.eu dbus-daemon[3499]: [system] Connection ":1.47" is not allowed to add more match rules (increase limits in configuration file if required; max_match_rules_per_connection=2048)

Every press of the key in terminal, generate 3 new lines in the log.
Solution:
For all programs.
Create the file /etc/dbus-1/system-local.conf with content

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE busconfig PUBLIC
	  "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
	  "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">

<busconfig>
<limit name="max_match_rules_per_connection">10000</limit>
</busconfig>

and reload dbus

If you want change limits only for mate terminal put the same content in the file /etc/dbus-1/system.d/org.mate.terminal.conf instead /etc/dbus-1/system-local.conf

Comment 17 Dominik 'Rathann' Mierzejewski 2018-05-15 07:46:23 UTC
(In reply to Paweł from comment #16)
> Same for f28 (mate-terminal)
> May 06 11:59:30 corsair.sunwire.eu dbus-daemon[3499]: [system] Connection
> ":1.47" is not allowed to add more match rules (increase limits in
> configuration file if required; max_match_rules_per_connection=2048)
> 
> Every press of the key in terminal, generate 3 new lines in the log.
> Solution:
[...]

Same here with mate-terminal on F28, thanks for the workaround, it works well!

Comment 18 RobbieTheK 2018-05-22 13:43:48 UTC
(In reply to Paweł from comment #16)
> Same for f28 (mate-terminal)
> May 06 11:59:30 corsair.sunwire.eu dbus-daemon[3499]: [system] Connection
> ":1.47" is not allowed to add more match rules (increase limits in
> configuration file if required; max_match_rules_per_connection=2048)
> 
> Every press of the key in terminal, generate 3 new lines in the log.
> Solution:
> For all programs.
> Create the file /etc/dbus-1/system-local.conf with content
> 
> <?xml version="1.0" encoding="UTF-8"?>
> 
> <!DOCTYPE busconfig PUBLIC
> 	  "-//freedesktop//DTD D-BUS Bus Configuration 1.0//EN"
> 	  "http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
> 
> <busconfig>
> <limit name="max_match_rules_per_connection">10000</limit>
> </busconfig>
> 
> and reload dbus

I tried this but everything on the desktop (GDM, Lightdm, KDM) just starts crashing with errors like this:

ourserver dbus-daemon[1673]: [system] Connection ":1.4416" is not allowed to add more match rules (increase limits in configuration file if required; max_match_rules_per_connection=10000)

May 21 09:19:49 storm gnome-shell[16634]: GNOME Shell started at Mon May 21 2018 09:19:24 GMT-0400 (EDT)
May 21 09:19:54 storm journal[17199]: book_client_connected_cb: Unable to connect to <E2><80><9C>Personal<E2><80><9D>: Error calling 
StartServiceByName for org.gnome.evolution.dataserver.AddressBook9: Timeout was reached
May 21 09:19:54 storm journal[16717]: Could not load source 'system-calendar': Timeout was reached
May 21 09:20:19 storm kernel: [315800.248445] traps: evolution-calen[17199] trap int3 ip:7fdaae129771 sp:7ffead0e4e60 error:0 in libglib-2.0.so.0.5400.3[7fdaae0d9000+111000]
May 21 09:20:19 storm kernel: [315800.259137] traps: evolution-calen[17045] trap int3 ip:7f5a675f2771 sp:7ffc03e06de0 error:0 in libglib-2.0.so.0.5400.3[7f5a675a2000+111000]
May 21 09:20:19 storm journal[16717]: Could not load source 'system-task-list': Timeout was reached
May 21 09:20:19 storm journal[17199]: creating thread '': Error creating thread: Resource temporarily unavailable
May 21 09:20:19 storm kernel: traps: evolution-calen[17199] trap int3 ip:7fdaae129771 sp:7ffead0e4e60 error:0 in libglib-2.0.so.0.5400.3[7fdaae0d9000+111000]
May 21 09:20:19 storm journal[17045]: creating thread 'Spawn-Subprocess-Backend': Error creating thread: Resource temporarily unavailable
May 21 09:20:19 storm kernel: traps: evolution-calen[17045] trap int3 ip:7f5a675f2771 sp:7ffc03e06de0 error:0 in libglib-2.0.so.0.5400.3[7f5a675a2000+111000]
May 21 09:20:19 storm abrt-hook-ccpp[17557]: Process 17199 (evolution-calendar-factory-subprocess) of user 16836 killed by SIGTRAP - ignoring (abrtd is not running)
May 21 09:20:19 storm abrt-hook-ccpp[17557]: If abrtd crashed, /proc/sys/kernel/core_pattern contains a stale value, consider resetting it to 'core'

Comment 19 Paweł 2018-05-22 16:58:02 UTC
(In reply to RobbieTheK from comment #18)

> > <limit name="max_match_rules_per_connection">10000</limit>
> > </busconfig>
> > 
> > and reload dbus
> 
> I tried this but everything on the desktop (GDM, Lightdm, KDM) just starts
> crashing with errors like this:

I use mate-desktop (with lightdm) and everything works for me.
Maybe try to increase the value from 10,000 to e.g. 20,000

Comment 20 RobbieTheK 2018-05-22 17:06:56 UTC
(In reply to Paweł from comment #19)
> (In reply to RobbieTheK from comment #18)
> 
> > > <limit name="max_match_rules_per_connection">10000</limit>
> > > </busconfig>
> > > 
> > > and reload dbus
> > 
> > I tried this but everything on the desktop (GDM, Lightdm, KDM) just starts
> > crashing with errors like this:
> 
> I use mate-desktop (with lightdm) and everything works for me.

Yep nice work-around, works perfectly and fast.

So is this a GDM bug?

Comment 21 Paweł 2018-05-22 17:11:15 UTC
> Yep nice work-around, works perfectly and fast.
> 
> So is this a GDM bug?

I don't think so. It is rather a problem with dbus.

Comment 22 Rajeesh 2018-07-18 08:42:52 UTC
Saw this today when the system was suddenly unresponsive. Had to hard reboot and this is what's left in journalctl:

dbus-daemon[604]: [system] Connection ":1.56" is not allowed to add more match rules (increase limits in configuration file if required; max_match_rules_per_connection=2048)

Using SDDM. Package versions:
dbus-1.12.8-1.fc28.x86_64
kernel-4.17.6-200.fc28.x86_64
sddm-0.17.0-3.fc28.x86_64

Comment 23 bugzilla.redhat.com@mno.pw 2018-08-14 19:31:40 UTC
Same / Similar issue here ...

Aug 14 21:29:33 anonymous dbus-daemon[13298]: [system] Connection ":1.2299" is not allowed to add more match rules (increase limits in configuration file if required; max_match_rules_per_connection=2048)

~ busctl status ":1.2299"
PID=23141
PPID=14163
TTY=n/a
UID=1000
EUID=1000
SUID=1000
FSUID=1000
OwnerUID=1000
GID=1000
EGID=1000
SGID=1000
FSGID=1000
SupplementaryGIDs=10 36 107 966 980 1000 1001
Comm=gnome-documents
Exe=/usr/bin/gjs-console
CommandLine=/usr/bin/gjs-console /usr/bin/gnome-documents --gapplication-service
Label=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
CGroup=/user.slice/user-1000.slice/user/dbus.service
Unit=user
Slice=user-1000.slice
UserUnit=dbus.service
UserSlice=-.slice
Session=n/a
AuditLoginUID=1000
AuditSessionID=3
UniqueName=:1.2299
EffectiveCapabilities=
PermittedCapabilities=
InheritableCapabilities=
BoundingCapabilities=cap_chown cap_dac_override cap_dac_read_search 
        cap_fowner cap_fsetid cap_kill cap_setgid 
        cap_setuid cap_setpcap cap_linux_immutable cap_net_bind_service 
        cap_net_broadcast cap_net_admin cap_net_raw cap_ipc_lock 
        cap_ipc_owner cap_sys_module cap_sys_rawio cap_sys_chroot 
        cap_sys_ptrace cap_sys_pacct cap_sys_admin cap_sys_boot 
        cap_sys_nice cap_sys_resource cap_sys_time cap_sys_tty_config 
        cap_mknod cap_lease cap_audit_write cap_audit_control 
        cap_setfcap cap_mac_override cap_mac_admin cap_syslog 
        cap_wake_alarm cap_block_suspend cap_audit_read

Comment 24 Ben Cotton 2019-05-02 20:33:59 UTC
This message is a reminder that Fedora 28 is nearing its end of life.
On 2019-May-28 Fedora will stop maintaining and issuing updates for
Fedora 28. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora 'version' of '28'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 28 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 25 Ben Cotton 2019-05-28 23:02:31 UTC
Fedora 28 changed to end-of-life (EOL) status on 2019-05-28. Fedora 28 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.


Note You need to log in before you can comment on or make changes to this bug.