Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1684917 - udisksd is consuming a lot of memory. [NEEDINFO]
Summary: udisksd is consuming a lot of memory.
Keywords:
Status: NEW
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: udisks2
Version: 8.0
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: rc
: 8.0
Assignee: Tomáš Bžatek
QA Contact: Storage QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-03-03 20:03 UTC by Siddhant Rao
Modified: 2019-04-10 13:05 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Type: Bug
Target Upstream Version:
sirao: needinfo? (tbzatek)


Attachments (Terms of Use)

Description Siddhant Rao 2019-03-03 20:03:25 UTC
Description of problem:

udisks service was consuming a lot of memory, nearly 32GB

   #   USER      PID    %CPU  %MEM  VSZ-MiB  RSS-MiB  TTY    STAT  START  TIME      COMMAND 
   66  root      27247  26.6  28.2  44391    36416    ?      -     2018   71039:47  /usr/libexec/udisks2/udisksd 

That being said, we have now restarted the service and now everything seems to be fine, Need to know what is the use of this service and why does it consume so much memory?

Version-Release number of selected component (if applicable):
udisks2-2.7.3-6.el7.x86_64

How reproducible:

Not able to reproduce on my system, was seen once on a customer's system.

Steps to Reproduce:
1.
2.
3.

Actual results:
udisks service was holding a lot of memory

Expected results:
udisks should not have been holding so much of memory on the Host.

Additional info:

This service was disabled by default on a fresh installed system.
The customer managed to find out that by navigating on the cockpit interfaces, On the storage section particularly, it triggered this service to start running.
Does cockpit have a direct relation with this service?. If yes then how?. also why is it retaining so much memory.

Comment 2 Tal Nisan 2019-03-04 09:30:12 UTC
Hi Siddhant, I think you opened this bug on the wrong product, it was opened on RHEV

Comment 3 Tomáš Bžatek 2019-03-04 10:42:31 UTC
(In reply to Siddhant Rao from comment #0)
> Additional info:
> 
> This service was disabled by default on a fresh installed system.
> The customer managed to find out that by navigating on the cockpit
> interfaces, On the storage section particularly, it triggered this service
> to start running.
> Does cockpit have a direct relation with this service?. If yes then how?.
> also why is it retaining so much memory.

Cockpit uses udisks for nearly all storage-related tasks. It also activates udisks modules for LVM and other things.

Is it possible get some logs of the service? Such big memory consumption indicates memory leaks, the daemon itself should stay reasonably low-footprint on memory and CPU. 

The total CPU time spent ("71039:47") is also large enough to indicate some kind of trouble. Is this a constant load or just a spike? Udisks generally responds to uevents (udev events), normally it should be quiet down to zero CPU utilization. Would be interesting to see what is the traffic situation in `udevadm monitor` as well.

Also, `udisksctl dump` output may help to understand customer's storage topology.


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