mate-panel high memory usage if build with in-process

[prarit]

Expected behaviour

mate-panel does not consume 9G of memory

Actual behaviour

mate-panel has consumed 9G of memory. Eventually attempting to start applications from the mate-panel will fail with memory errors. Starting the application from a previously opened terminal does work.

Steps to reproduce the behaviour

Unknown. I am using the mate desktop on my day-to-day workstation. I am not doing anything unusual.

MATE general version

mate-about shows version 1.20.1

mate-desktop-1.20.1-3.fc27.x86_64

Package version

mate-panel-1.20.1-5.fc27.x86_64

Linux Distribution

F27

Link to downstream report of your Distribution

[prarit]

Link to downstream report of your Distribution

https://bugzilla.redhat.com/show_bug.cgi?id=1576930

P.

[raveit65]

Do you use windows-applets via wine in na-tray? See https://bugzilla.redhat.com/show_bug.cgi?id=1575091

[prarit]

On 05/10/2018 03:02 PM, raveit65 wrote:

Do you use windows-applets via wine in na-tray? See https://bugzilla.redhat.com/show_bug.cgi?id=1575091

Nope, I'm not using wine or any windows apps. I can reproduce the problem right now. These are the open applications I have: xterm, thunderbird, hexchat, firefox, mate terminal, and libreoffice. In previous instances where this has happened I've had everything but libreoffice open.

P.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/mate-desktop/mate-panel/issues/809#issuecomment-388152729, or mute the thread https://github.com/notifications/unsubscribe-auth/ALY9W-KUOOT83k3CKmjWbh3RT0xqEAZdks5txI61gaJpZM4T6XQ0.

[prarit]

Current mate-panel memory consumption is over 50%: 2203 prarit 20 0 14.706g 0.013t 26864 S 5.3 50.9 98:26.53 mate-panel

If I attempt to launch any application through the panel I get a "Failed to fork (cannot allocate memory)" error.

[prarit]

OOC (I couldn't find an answer searching online) is there a way to restart the mate-panel? I know of "--reset" but that kills all my settings.

[raveit65]

'killall mate-panel', restart happens automatic via session management.

[raveit65]

which is 'kill -9'

[lukefromdc]

How long does that workstation normally run between reboots? How long on a new boot before you see 9GB of RAM consumed by the panel?

Right now, after 6 min run on a new boot(encrypted machine always shut down when not in use), I see 38MB in use. I've seen 60 or so in long, complex sessions but that's about it

[alexarnaud]

Le 11/05/2018 à 01:12, prarit a écrit :

Nope, I'm not using wine or any windows apps. I can reproduce the problem right now. These are the open applications I have: xterm, thunderbird, hexchat, firefox, mate terminal, and libreoffice. In previous instances where this has happened I've had everything but libreoffice open.

Thank you prarit for this bug report.

Could you tell us which version has caused the issue ?

As we're not able to reproduce your issue, we'll need to determine what's happened.

To do that you could do: 1) Close all your opened applications 2) Restart Mate Panel 3) Check the memory usage 4) Go to take a coffee or something else :) 5) Check after 5-10 minutes the memory usage

If the memory usage stays constant it's an application that causing the issue.

To determine which software could be the culprit could you open application one by one and check the memory usage after 5-10 minutes ?

Could you tell us the result of the following command ?

gsettings get org.mate.panel enable-sni-support

I know I'm requesting to you a little bit of investigation but it's crucial for us to be able to identify what is the issue and how we could figure it out.

Best regards, Alex.

[raveit65]

If I attempt to launch any application through the panel I get a "Failed to fork (cannot allocate memory)" error.

With a panel launcher, from menu or with alt+f2

[prarit]

On 05/10/2018 11:21 PM, lukefromdc wrote:

How long does that workstation normally run between reboots? How long on a new boot before you see 9GB of RAM consumed by the panel?

Since the last yum update on my system (12 days ago) I have had to restart mate every 4 days. I just did a restart yesterday.

It was suggested in the Fedora BZ (see link above) that I install a new version of mate-panel. I have done that in effort to see if the new version resolves the problem. I will let everyone know, both in this bug report, and in the BZ if after 4 days my system is stable.

One interesting piece of information in the BZ is that a previous user (who was using wine) was also running on a VNC session. That might have something to do with reproducing this problem.

Right now, after 6 min run on a new boot(encrypted machine always shut down when not in use), I see 38MB in use. I've seen 60 or so in long, complex sessions but that's about it

After about 7 hours I get ~ the same value that you do.

[prarit@prarit ~]$ uptime 07:37:35 up 12:12, 3 users, load average: 0.34, 0.39, 0.35 [prarit@prarit ~]$ ps -eo rss,pid,euser,args:100 --sort %mem | grep -v grep | grep -i mate-panel | awk '{printf $1/1024 "MB"; $1=""; print }' 22.8438MB 2598 prarit /usr/libexec/mate-panel/notification-area-applet 29.6758MB 2594 prarit /usr/libexec/mate-panel/wnck-applet 32.5781MB 2596 prarit /usr/libexec/mate-panel/clock-applet 33.418MB 2196 prarit mate-panel

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/mate-desktop/mate-panel/issues/809#issuecomment-388248559, or mute the thread https://github.com/notifications/unsubscribe-auth/ALY9W-wKTmROU7JUxBrKB8yTwbdrrGp8ks5txQPWgaJpZM4T6XQ0.

[prarit]

On 05/11/2018 04:22 AM, Alex ARNAUD wrote:

Le 11/05/2018 à 01:12, prarit a écrit :

Nope, I'm not using wine or any windows apps. I can reproduce the problem right now. These are the open applications I have: xterm, thunderbird, hexchat, firefox, mate terminal, and libreoffice. In previous instances where this has happened I've had everything but libreoffice open.

Thank you prarit for this bug report.

Could you tell us which version has caused the issue ?

mate-panel-1.20.1-5.fc27.x86_64

As we're not able to reproduce your issue, we'll need to determine what's happened.

To do that you could do: 1) Close all your opened applications 2) Restart Mate Panel 3) Check the memory usage 4) Go to take a coffee or something else :)

Sudoku? :)

5) Check after 5-10 minutes the memory usage

https://bugzilla.redhat.com/show_bug.cgi?id=1576930#c2

it is suggested I upgrade to a new mate-panel build. I have done so and will report back in 4 days to see if the problem occurs again.

If the memory usage stays constant it's an application that causing the issue. Hmm. OOC, how would you make that determination?

To determine which software could be the culprit could you open application one by one and check the memory usage after 5-10 minutes ?

Yup, I can definitely do that but I'd like to wait the 4 days to see if the new build works.

Could you tell us the result of the following command ?

gsettings get org.mate.panel enable-sni-support

I know I'm requesting to you a little bit of investigation but it's crucial for us to be able to identify what is the issue and how we could figure it out.

No, no no ... :) Not a big deal. I love the mate desktop and I have no problem helping out debugging.

Noting that I'm running the suggested new build

[07:42 AM root@prarit ~]# gsettings get org.mate.panel enable-sni-support false

Best regards, Alex.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/mate-desktop/mate-panel/issues/809#issuecomment-388296323, or mute the thread https://github.com/notifications/unsubscribe-auth/ALY9W14E8TuNhtn3ii6596WKpf_Cw1ioks5txUpBgaJpZM4T6XQ0.

[alexarnaud]

Le 11/05/2018 à 13:43, prarit a écrit :

If the memory usage stays constant it's an application that causing the issue. Hmm. OOC, how would you make that determination?

I assume if that was a general issue, we'll all be impacted by the problem. As I think nothing is magic in computing something causing the issue somewhere.

Best regards, Alex.

[lukefromdc]

Since another report indicated the tray built in-process was a cause of this, I ran cppcheck-gui on the notification-area directory with all the messages turned on, and got these results which don't show anything that would be expected to be the cause of this:

na-resources.c,0,information,The configuration '_MSC_VER;_WIN64' was not checked because
its code equals another one.

na-resources.c,0,information,The configuration '__ELF__' was not checked because its code
equals another one.

main.c,0,information,The configuration 'GDK_WINDOWING_X11' was not checked because its
code equals another one.

na-box.c,0,information,The configuration 'GDK_WINDOWING_X11' was not checked because its
code equals another one.

libstatus-notifier-watcher/gf-sn-watcher-v0-gen.c,1754,style,The scope of the variable 'variant'
can be reduced.

libstatus-notifier-watcher/gf-sn-watcher-v0-gen.c,0,information,The configuration
'HAVE_CONFIG_H' was not checked because its code equals another one.

status-notifier/sn-dbus-menu-gen.c,3125,style,The scope of the variable 'variant' can be
reduced.

status-notifier/sn-dbus-menu-gen.c,0,information,The configuration 'HAVE_CONFIG_H' was not
checked because its code equals another one.

system-tray/na-tray-manager.c,54,style,struct member 'PendingMessage::id' is never used.

system-tray/na-tray-manager.c,54,style,struct member 'PendingMessage::len' is never used.

system-tray/na-tray-manager.c,55,style,struct member 'PendingMessage::remaining_len' is
never used.

system-tray/na-tray-manager.c,57,style,struct member 'PendingMessage::timeout' is never
used.

system-tray/na-tray-manager.c,58,style,struct member 'PendingMessage::str' is never used.

status-notifier/sn-watcher-v0-gen.c,1754,style,The scope of the variable 'variant' can be
reduced.

status-notifier/sn-watcher-v0-gen.c,0,information,The configuration 'HAVE_CONFIG_H' was not
checked because its code equals another one.

status-notifier/sn-item-v0-gen.c,2809,style,Variable 'value' is reassigned a value before the old
one has been used.

status-notifier/sn-item-v0-gen.c,2837,style,Variable 'value' is reassigned a value before the old
one has been used.

status-notifier/sn-item-v0-gen.c,2865,style,Variable 'value' is reassigned a value before the old
one has been used.

status-notifier/sn-item-v0-gen.c,2893,style,Variable 'value' is reassigned a value before the old
one has been used.

status-notifier/sn-item-v0-gen.c,3620,style,The scope of the variable 'variant' can be reduced.

status-notifier/sn-item-v0-gen.c,0,information,The configuration 'HAVE_CONFIG_H' was not
checked because its code equals another one.

status-notifier/sn-host-v0-gen.c,0,information,The configuration 'HAVE_CONFIG_H' was not
checked because its code equals another one.

[prarit]

The build in https://bugzilla.redhat.com/show_bug.cgi?id=1576930#c2 works AFAICT. mate-panel has very low memory usage:

2196 prarit 20 0 749068 73236 22052 S 0.0 0.3 0:14.88 mate-panel

[raveit65]

Ok, sounds like i have to switch mate-panel build back to out-of process in fedora. @prarit Can you do a last test for us again? We like to know which applet causes the high load? Because building panel with applet in-process (fedora repo version)= all applets from mate-panel package use the same process. Building panel with applets out-of-process (test build and old builds)= every applet use a single process.

That means the high load of the panel process is caused by an applet. So can you test panel build from repos without notification-area-tray? We need to know if this applet is the culprit. Or not with all na-tray applets which you are using normal? To find out which tray-applet causes the issue.

I know this isn't very comfortable...........thank you.

[lukefromdc]

Why is this different in Fedora than in Debian is the other question. Rather hard to work on this when I can't get it to happen here.

[raveit65]

Why is this different in Fedora than in Debian is the other question. Rather hard to work on this when I can't get it to happen here.

I think you don't use his application-tray-applet which trigger the issue, maybe?

[prarit]

That means the high load of the panel process is caused by an applet. So can you test panel build from repos without notification-area-tray? We need to know if this applet is the culprit. Or not with all na-tray applets which you are using normal? To find out which tray-applet causes the issue.

Sure ... If you can give me detailed instructions on what you'd like me to do :)

[raveit65]

I thought that was instruction enough :) All with culprit version from fedora repos.

First test without using the tray-applet in panel.

1. right click on the grid area left from na-tray applet. Here choose un-lock the applet.
2. right-click again and choose remove the applet.

Second test with the na-tray-applet. I don't know which application you use which are loading applets inside the na-tray-applet :) Most applications with tray-applets have an option to disable the tray applet.

[prarit]

I see, you want me to trim down my applets :). I'm going to figure out a way to do this. The problem is that the vnc session I run in is my main desktop :( so I'm adverse to doing any testing there.

BUT :) I do have room to create more guests on my host. I'm going to see if I can create a new F27 test environment and see if I can reproduce. Again, keep in mind that the test takes ~4 days before reproducing so this is going to take some time to figure out.

[vkareh]

@raveit65 - is this actually solved by building out of process? Can we change the default to be the clock and window list in process, everything else out of process? I've been working on this issue for quite a while and those are the only two applets that flicker. Also, I have a hack for the window-list one, so really it would be just the clock...

[vkareh]

@lukefromdc - I've seen several reports of this on Ubuntu, so it is an issue there as well. @raveit65 - Ubuntu uses the na-tray applet as well, but most of the icons are in the indicator applet instead (default layout has both applets actually)

[raveit65]

@vkareh Yes, the issue doesn't exists if the panel i build out of process and i agree with your suggestion. I'd love to see several in/out-of-process build options for building the applets independent. Building the na-tray appet in-process is needed in future for switching to wayland, than such issues needs to be fixed. But than GtkStatusIcon is also dropped by gtk+4 ;) So, at the moment this isn't really relevant. But maybe we're lucky and we get more infos what exactly caused the issue from reporter, in result someone can reproduce it for fixing.

I've seen several reports of this on Ubuntu, so it is an issue there as well.

Is there one report with very specific tray applet which causes the issue? I know that it can happen with wine applets, but this is one thing which i don't want to install on my box ;)

[vkareh]

https://ubuntu-mate.community/t/mate-indicator-applet-using-5gb-ram/16844

Huh... That's for the indicator applet... :confused:

[raveit65]

I just switched back fedora builds to out of process. https://bodhi.fedoraproject.org/updates/FEDORA-2018-f11f17bf17 https://bodhi.fedoraproject.org/updates/FEDORA-2018-7cbfe6ab39 I suggest to leave the report open for finding the real culprit for this issue.

[lfir]

Hello. I'm also having this issue on Fedora 27 (mate-panel-1.20.1-5.fc27.x86_64). I tried removing the notification area and then it didn't occur any more. The only applets I've running are the ones for the printer (/usr/share/system-config-printer/applet.py), network (NetworkManager Applet nm-applet) and volume (mate-volume-control-applet). I killed all of them but the memory consumption of mate-panel remains the same. Regards.

[vkareh]

@Asta1986 - this is quite useful, actually. So you're saying that even with no icons showing in the notification area you still had high memory consumption? That must mean that the issue is with the applet itself, rather than with a specific icon that shows there...

[lfir]

@vkareh Right. Also I see it doesn't consume much memory in my machine if mate-panel starts without the notification area at all or the process is restarted. Regards.

[lukefromdc]

How would I go about diagnosing this when I use an encrypted system that has to be shut down all the way anytime it is left unguarded? I have Valgrind installed but don't know much about how to use it.

[lukefromdc]

I just found that running the panel under valgrind finds a torrent of errors. In just a very limited partial log of one run (could not select it all there was so much) I got 76 instances of

Conditional jump or move depends on uninitialised value(s)

This error (maybe a memory leak?) showed up 8 times in different places:

Address 0x4327c5c is 4 bytes after a block of size 32 free'd

There were literally thousands of errors overall. I have wncklet, tray, clock built in-process. Fish too but not in this panel.

I got this leak summary after another run, terminated before the tray even appeared: definitely lost: 9,048 bytes in 114 blocks Oh yeah we've got memory leaks in the panel

[lukefromdc]

Looking at the panel code I have found only one code difference for in-process vs out-of-process: this block in main.c:

#ifdef NOTIFICATION_AREA_INPROCESS
    MATE_PANEL_APPLET_IN_PROCESS_FACTORY ("NotificationAreaAppletFactory",
                 NA_TYPE_TRAY_APPLET,
                 "NotificationArea",
                 applet_factory,
                 NULL)
#else
    MATE_PANEL_APPLET_OUT_PROCESS_FACTORY ("NotificationAreaAppletFactory",
                  NA_TYPE_TRAY_APPLET,
                  "NotificationArea",
                  applet_factory,
                  NULL)
#endif

Note that the status icon specification uses GtkSocket at the tray end, and this is thus the only applet that uses GtkSocket for anything when built in-process. The GtkStatusIcons created by applications are embedded in the tray by the plug/socket system in all cases. We need to find out where this goes wrong when in-process

[lukefromdc]

Can anyone who gets the memory leak test gnome-panel (all applets are in-process with it) for as long as it takes to notice the memory leak? If it does not exist there, than some commit to gnome-panel is probably the difference.

[lukefromdc]

@prarit, are you running mate-panel with SNI (indicator) support enabled or disabled?

I just found this commit for the status notifier in gnome-panel that fixes a memory leak: https://github.com/GNOME/gnome-panel/commit/6f4b078da832fbaed2fa5156d2e46b70e9870a7c

And while there are other commits to mate-panel to plug other memory leaks in SNI support, this one is not present, and the key phrase from it "menu_item_finalize" is not found anywhere in our tray code.

EDIT2: It looks like we don't have that commit because it is for a whole section of code we don't use. I also need to find out what is being done differently in and out of process with those GtkPlugs used for regular tray icons (status icons).

[lukefromdc]

Try https://github.com/mate-desktop/mate-panel/pull/846 and see if that makes any difference. It's one of the few codepath differences for in-process, and I noticed an error handler used for GtkPlug/Socket widgets was being excluded from in-process applets, while the in-process tray is still using them to embed the tray icons themselves.

[lukefromdc]

I just did some testing with experimental https://github.com/mate-desktop/mate-panel/pull/846 and some calculations for the reported memory leak.

Did not see any at-idle growth in panel RAM use in maybe 10-15 minuites, with a resolution of 100KB in mate-system-monitor, but I don't think I had that before either. The reported 9GB memory leak in 7 days is 1.28GB per day, which is 54MB per hour or almost 1 MB per minute.

I did find that RAM jumped to about 40.7MB after opening and using (thus closing) the panel run dialog. The RAM used when this is opened stays in use when it is closed, so that is a memory leak, though it looks like it may be worst on the first time the run dialog is used.

Also in some cases but not all, adding and removing a tray icon would leave behind an unfree 100KB or so of RAM. @prarit , any chance you have something interacting with the tray on a timer? We do have a report of high RAM use with no icons in the tray at all, but what I found suggests that if an app were constantly replacing the icon as a way of updating it, this 10oBK or so memory leak on a per-removal basis would quickly add up.

EDIT: Opening and closing the main menu a few times (I have a big one) and opening some submenus jumped RAM use to 61.8MB, and it stayed up when the menu was closed. That might be an intended behavior if the menu loads its content when first popped up and then is kept around, as appears to be the case with these menus in general. Once all the menus have been open, I didn't see much futher increase.

[raveit65]

@lukefromdc off topic and not related to na-tray applet I noticed that only switching the panel from theme to transparency background and back gives me a significant mem leak. start 46.5 MIB before switching transparancy 49.5 MIB with trancparancy 133 MIB switching back to theme background 58.7 MIB

Should i open an extra report for this?

[muktupavels]

I doubt you have memory leak just because it is in-process... The only difference might be that with in-process applet you see this memory leak in mate-panel process, but when applet is out-of-process then this leak should be in other process.

Run na-tray applet with valgrind and see what it tells you... Same goes with background changing, run mate-panel with valgrind.

[raveit65]

@prarit With current fedora build (all applets are build with out-of-process). Do you see an increasing memory consumption with notification-area-applet process after several days?

[raveit65]

I can confirm the observation of opening/closing menus/contex-menus. After a fresh panel start those actions can increase the memory consumption a bit, but after the panel is running a while those action don't increase the memory consumption again.

[lukefromdc]

Any chance the big (9GB/7 days) memory leak occurs only with the panel in HiDPI mode? If you are seeing this massive RAM usage, what is your monitor resolution and window-scaling?

[prarit]

@lukefromdc I haven't seen any issues running mate-panel-1.20.2-1.fc27.x86_64. I do have notifications on the panel (hexchat) and the clock running. I am also running via vncserver so my resolution changes depending on where I'm running (home, work laptop, desktop).

[prarit]

To reiterate: What I saw was leaving my desktop IDLE caused the a memory leak. Let me kick a new VM & vnc session and see if I can reproduce with mate-panel-1.20.1-5.fc27.x86_64 & mate-desktop-1.20.1-3.fc27.x86_64.

[prarit]

I've kicked the test. Let's wait a few days and see what happens.

[lukefromdc]

I am not on Fedora but rather Debian Unstable with locally built MATE packages. If the mate-panel build you are running has the tray out of process you should either have no memory leak or a memory leak in the tray applet (separate process) and not in mate-panel. If the panel is built in-process, any memory leak from the tray would show up as being in mate-panel itself.

Meanwhile, I will look at the idle callback and everything coming from it to see if I can find any issues there.

[lukefromdc]

I did some digging into the tray idle callbacks. We have:

static gboolean
idle_redraw_cb (NaTray *tray)
{
  NaTrayPrivate *priv = tray->priv;

  g_hash_table_foreach (priv->trays_screen->icon_table,
                        (GHFunc) na_tray_child_force_redraw, NULL);

  priv->idle_redraw_id = 0;

  return FALSE;
}

which calls na_tray_child_force_redraw, which well after this report was filed was simplified in master with https://github.com/mate-desktop/mate-panel/commit/9de3a86d736f70c4d45550649ba62a935369b146 which removed a lot of older expose handling code, and a code block that would not even build if a conditional that stopped its build was removed. The current code there is now just:

void
na_tray_child_force_redraw (NaTrayChild *child)
{
  GtkWidget *widget = GTK_WIDGET (child);

  if (gtk_widget_get_mapped (widget))
    {
    /* Hiding and showing is the safe way to do it, but can result in more
     * flickering.
     */
    gtk_widget_hide(widget);
    gtk_widget_show_all(widget);
    }
}

So I am wondering if the block of code that was removed here had any impact on memory leakage.

This code is in turn called only from na_tray_force_redraw

static void
na_tray_force_redraw (NaHost *host)
{
  NaTray *tray = NA_TRAY (host);
  NaTrayPrivate *priv = tray->priv;

  /* Force the icons to redraw their backgrounds.
   */
  if (priv->idle_redraw_id == 0)
    priv->idle_redraw_id = g_idle_add ((GSourceFunc) idle_redraw_cb, tray);
}

Which in turn is called from na_host_init

static void
na_host_init (NaHostInterface *iface)
{
  iface->force_redraw = na_tray_force_redraw;
  iface->style_updated = na_tray_style_updated;
}

Does anyone see anything in this code from git master as of July 24 that would be expected to leak memory at idle with no icons in the tray?

[lukefromdc]

The code block removed in https://github.com/mate-desktop/mate-panel/commit/9de3a86d736f70c4d45550649ba62a935369b146 in na_tray_child_force_redraw set quite a few variables, and I didn't see any of them being explicitly freed in the old code. Some of them no doubt could not be, and others would be gone after the function closed, but even one that needed to be freed and was not could cause a substantial memory leak over days of running when in code activated by an idle callback.

Thus, a build with the tray in-process should be tested under the same conditions that led to that 9GB ram usage in a week with mate-panel-1.20.1-5.fc27.x86_64 to see if this made any difference

[prarit]

I can't reproduce it :(

[lukefromdc]

So this time around, same mate-panel version where you got the memory leak before, but no memory leak now? If the memory leak still existed with an empty tray and you had it then but not now, maybe a change in an underlying library stopped it, and that might also explain why I never saw it once. I have seen other memory leaks, but nothing comparable to 9GB in 7 days, which would be 300+ MB in just six hours of use, which I've never once see. Despite memory leaks when opening and closing the menu, and another on adding and removing tray icons I've never seen over 80MB used by the tray, and it starts up at about 37MB. It should stay there of course.

[raveit65]

I did a test with latest mate-panel from master and using a transparent panel, memory consumption is higher in this case.

build all out-of-process, panel start time: 11:00 end time: 00:36

panel start 96,5 MIB, end 144,5 MIB notification-area-applet start 28,1 MIB, end 30,2 MIB clock-applet start 39,8 MIB, end 43,0 MIB wncklet-applet start 30,9 MIB, end 36,0 MIB

• from mate-applets mate-cpufreq-applet start 28,4 MIB, end 28,3 MIB mate-multiload-applet start 29,8 MIB, end 29,6 MIB mate-weather-applet start 36,9 MIB, end 38,1 MIB

• other mate applets mate-sensor-applet start 30,1 MIB, end 30,4 MIB streamer-applet start/iddle 34,2 MIB, play music 62,3 MIB, end 59,5 MIB

• tray applets keypassXC (no single process) display-applet (no single process) nm-applet start 34,6 MIB, end 33,5 MIB mate-voluume-control start 31,6 MIB, end 32,8 MIB abrt-applet (not visible) start 19.6 MIB, end 24,3 MIB system-config-printer (not visible) start 33,0 MIB, end 33,0 MIB