-3

OS: Ubuntu 16.04

free output indicated about 2GB of shared memory. The shared memory was still allocated after a logout, and no particular process from top list was occupying it.

ipcs -m did not indicate any singular process (or sum) with this consumption.

sync or sysctl vm.drop_caches={1..3} did not reduce the shared memory. (only the cache as expected)

After the fact I know that the issue was caused by a faulty attempt to write to block device with dd, which caused a physical file to be created in /dev/ (see answer).

for reference:

> grep ' /dev ' /proc/mounts 
udev /dev devtmpfs rw,nosuid,relatime,size=1941504k,nr_inodes=485376,mode=755 0 0

What steps are needed in general to find out what is occupying shared memory?

closed as unclear what you're asking by LinuxSecurityFreak, G-Man, Jeff Schaller, Stephen Rauch, sebasth Nov 3 '17 at 22:13

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    Hi! Even when you intend to answer your own question, I think it would be best to phrase your question as a question (e.g. "How to free 2GB of shared memory I cannot seem to get rid of?"). This helps make it clearer exactly what questions you will be answering. – dhag Nov 3 '17 at 17:54
  • 1
    Question must be phrased to be answerable here. Provide details. Otherwise we'll close it as non-reproducible or another off-topic. – LinuxSecurityFreak Nov 3 '17 at 18:01
  • tried to rewrite the text as a question. – IljaBek Nov 3 '17 at 23:37
  • The updated question is clearer now, and I would vote to reopen it, but based on your answer it's clear that this was caused by a typo and has no other "correct" answer, so I will be voting to leave it closed. – Jeff Schaller Nov 4 '17 at 0:07
  • I have no idea if I have violated the rules, if so sorry to have done so. It was an unexpected cause and effect situation - I would not expect a physical file in /dev/ to have an effect on memory calculation. Since I'm not sure it's a bug, I'm solely reporting about it in case someone else encounters it. – IljaBek Nov 4 '17 at 0:13
1

The reason was me making a typo in dd command, writing to a physical file /dev/mmcblk1:

 > ll /dev/mmcblk*
-rw-r--r-- 1 root root   1.9G 2017-11-03 18:09 /dev/mmcblk1 
brw-rw---- 1 root disk 179, 0 2017-11-03 18:10 /dev/mmcblk2

after removing the SD card and noticing the mistake, I have removed the physical file and the cache usage dropped by these 2GB.

example to reproduce:

> free -h
              total        used        free      shared  buff/cache   available
Mem:           3.7G        1.7G        919M        163M        1.2G        1.6G

> sudo dd if=/dev/zero of=/dev/BIG  bs=1M count=700 status=progress
700+0 records in
700+0 records out
734003200 bytes (734 MB, 700 MiB) copied, 0.743527 s, 987 MB/s

> free -h
              total        used        free      shared  buff/cache   available
Mem:           3.7G        1.7G        221M        859M        1.8G        982M

> sudo rm /dev/BIG

> free -h
              total        used        free      shared  buff/cache   available
Mem:           3.7G        1.7G        904M        160M        1.2G        1.6G

Not the answer you're looking for? Browse other questions tagged or ask your own question.