4

I have /private/var/db/uuidtext/dsc directory full of files. Directory size is >100GB and constantly growing. I've deleted all the files and also tried to reboot my mac, but it doesn't help. I've found little info about this directory, but it looks like that these files are log files, but I'm not able to figure out which process causes such a logging.

Is there any way to figure out what causes this heavy logging?

2
  • 2
    Please add two infos: your version of macOS and: is the size really that huge immediately after erase and reboot? Apr 8, 2019 at 8:12
  • I use Mojave 10.14.4. After deleting all the logs, it created about 100-200MB/30s. There was huge IO load on the mac so it was barely usable. reportcrash process used a lot of CPU so finally I switched it off. I also run the OnyX to clean up the system. One of them solved the problem after rebooting the machine. I'm still unsure what caused the problem.
    – Hubidubi
    Apr 9, 2019 at 9:03

3 Answers 3

2

As described in my comment to @bmike's answer, I had similar issues where /private/var/db was occupying too much space.

To check how much disk space is used, we run du on the directory:

sudo du -h /private/var/db | sort -h

...
201M    /private/var/db/uuidtext/dsc
283M    /private/var/db/receipts
283M    /private/var/db/audiotext
311M    /private/var/db/diagnostics/Persist
422M    /private/var/db/diagnostics
1,4G    /private/var/db

As I erased the content of my log yesterday, the "diagnostics" folder is not anymore 1.3G but "only" 422M. But it is clearly visible that "diagnostics" is the biggest consumer currently.

Now we can use the log command to collect statistics about the logs kept on disk:

log stats --overview

== archive =============================================================
size:               428’592’976 bytes
                    2’076’477’945 bytes (uncompressed)
start:              Mon May 22 21:36:00 2023
end:                Tue May 23 22:24:15 2023
statedump:          2’987

events:             [       total        log      trace   signpost       loss ]
                    [  14’820’415 12’614’086          0  1’708’567        234 ]

activity:           [      create transition     action ]
                    [     493’988          0        522 ]

log messages:       [     default       info      debug      error      fault ]
                    [  10’007’820    382’093    168’182  2’168’000  1’596’558 ]

ttl:                [        1day      3days      7days     14days     30days ]
                    [      16’115    267’332    244’540  1’844’891      3’868 ]

processes:          
          [        events (%total),  decomp. bytes (%total),                           image UUID, image ]
          [     3’492’040 ( 23.6%),  1’132’303’470 ( 54.5%), 9B51F175-B010-360F-ADCE-ADF6DC4824E4, Citrix Viewer ]
          [     1’564’636 ( 10.6%),    146’436’706 (  7.1%), 465422C7-3CFC-3E9F-9C04-813F3A265AA6, WindowServer ]
          [     1’559’844 ( 10.5%),    100’699’482 (  4.8%), 6E10EA79-C562-337C-8EDD-7A33479E7B25, bluetoothd ]
          [       955’906 (  6.4%),     96’068’735 (  4.6%), C6D3E63E-8B9A-3C70-9836-D751398CC501, kernel ]
          [     1’072’851 (  7.2%),     93’345’800 (  4.5%), 7ACE5B70-4C91-32DB-9252-22E15B48D5EE, launchd ]

senders:            
          [        events (%total),  decomp. bytes (%total),                           image UUID, image ]
          [     3’145’092 ( 21.2%),  1’103’917’848 ( 53.2%), 6E4B26DB-CB46-3487-B01E-A9BE22D160DF, AudioToolboxCore ]
          [     1’186’639 (  8.0%),    119’106’238 (  5.7%), 96676A53-B1E0-3D7E-B98B-B73873CD1880, SkyLight ]
          [     1’072’851 (  7.2%),     93’345’800 (  4.5%), 7ACE5B70-4C91-32DB-9252-22E15B48D5EE, launchd ]
          [       470’388 (  3.2%),     91’912’492 (  4.4%), F62B9AAC-1492-3A32-A6BF-77F8C26A0262, Network ]
          [     1’282’685 (  8.7%),     64’908’843 (  3.1%), 6E10EA79-C562-337C-8EDD-7A33479E7B25, bluetoothd ]

From the summary, we can read about the "size" occupied by the logs: on disk ~420M (=confirmed by du on the "diagnostics" folder) and uncompressed ~2G. Also we see the timestamp of the first ("start") and last ("end") event logged. You can see, that I cleared my log yesterday, and that all those logs have been generated within one day.

Further we can find in the summary the processes which generate most of the logs: "Citrix Viewer" triggered 3.5M log events (which is ~23% of all logs) which occupy 1G uncompressed memory).

So now that we know what application is running havoc and should be troubleshooted, we want ensure that the valuable space on our SSD is released. This can be done using: sudo log erase --all

This will release all the space occupied by /private/var/db/diagnostics.

I haven't found a way to delete the content in /private/var/db/uuidtext/dsc as it will immediately reappear. This is caused by logd or logd_helper having them open and constantly writing to them. (see the sudo fs_usage -w | grep uuidtext output as explained by @bmike)

But it seems that reinstalling macOS would be a possible solution (source: Apple Discussion forums and my own experience 9 months ago, when I installed macOS Ventura 😐)

1

Sure - the fsusage tool can show all filesystem operations live and you can sort on that path to determine what is doing the writing and back into the details.

sudo fs_usage -w | grep uuidtext

As you mention, the system can self fix by restart and updates. I’d guess OnyX didn’t help, but we’ll need to wait to get it to recur to know for sure.

Also, that directory is where the unified logs are stored, so you could also just inspect your normal logs in console app - if you have a high volume of logs, then your growth is normal and you’d uninstall / fix / suppress whatever is generating all the volume in the logging system.

log stream --info --debug

Also, most people are stunned and shocked to see how many thousands of info and debug messages get logged each and every second on a perfectly healthy mac, so don’t worry if you feel the volume is high without comparing to other computers. Maybe getting stats would be a better indicator:

me@dev ~> log stats --overview
== archive =============================================================
size:               461,012,272 bytes
                    1,141,374,160 bytes (uncompressed)
start:              Fri Jul 19 06:37:25 2019
end:                Sun Aug 18 17:56:08 2019
statedump:          725

events:             [       total        log      trace   signpost       loss ]
                    [  26,036,074 18,105,986         26    234,083          5 ]

activity:           [      create transition     action ]
                    [   7,694,844          0         10 ]

log messages:       [     default       info      debug      error      fault ]
                    [  17,799,660    219,169    105,002    215,663        601 ]

ttl:                [        1day      3days      7days     14days     30days ]
                    [           0     11,021     10,620     94,679     68,285 ]

processes:          
          [        events (%total),  decomp. bytes (%total),                           image UUID, image ]
          [     4,728,900 ( 18.2%),    137,984,377 ( 12.1%), 6848C8B5-B410-3D5E-B1F5-6A289006E83F, Activity Monitor ]
          [       800,052 (  3.1%),    100,277,357 (  8.8%), 9C895392-8753-316E-80F0-802610ED6A2C, AssetCache ]
          [     6,498,211 ( 25.0%),     90,979,241 (  8.0%), 26E8D205-980A-3139-B41A-BA2D40EE6294, diskarbitrationd ]
          [        12,103 (  0.0%),     82,909,480 (  7.3%), DF2BBC3F-1663-395D-BEA3-85172E5D5654, sandboxd ]
          [         9,827 (  0.0%),     79,484,156 (  7.0%), 03F25350-02B7-34AD-AF61-5001FCD85D39, sandboxd ]

senders:            
          [        events (%total),  decomp. bytes (%total),                           image UUID, image ]
          [     6,498,207 ( 25.0%),     90,979,122 (  8.0%), 26E8D205-980A-3139-B41A-BA2D40EE6294, diskarbitrationd ]
          [       682,424 (  2.6%),     86,726,296 (  7.6%), 74A0A926-957A-3803-9837-CF24592E46D3, libboringssl.dylib ]
          [       145,587 (  0.6%),     82,984,590 (  7.3%), 6993BD8C-C535-3AD7-B511-94EABF989658, GPUWrangler ]
          [        12,027 (  0.0%),     82,908,562 (  7.3%), DF2BBC3F-1663-395D-BEA3-85172E5D5654, sandboxd ]
          [         9,567 (  0.0%),     79,480,144 (  7.0%), 03F25350-02B7-34AD-AF61-5001FCD85D39, sandboxd ]

So 26 million events logged on a computer over a month and it was powered off for 2 weeks this month and lightly used the other couple weeks. On a busy computer I’d see this volume every week and not worry.

2
  • 1
    My logs were occupying 1.3GB (compressed! 11GB uncompressed) in /private/var/db/diagnostics. After using sudo log erase --all the space was freed.
    – pd95
    May 22, 2023 at 19:38
  • That would make an excellent addition to tack on to the end of my answer. Explain how you measured the size - what command you used and the results. I think having your log erase experience would help other people if it were in a stand alone answer or an edit to mine explaining how to detail the sizes. I learned a lot from your comment - thanks @pd95
    – bmike
    May 22, 2023 at 20:12
1

just solved this. this slowed down the device to a the point that there was a delay typing commands and i was unable to update the system before the SSD would be full.

echo pffff >> dsc; sudo rm -rf /private/var/db/uuidtext/dsc; sudo cp dsc /private/var/db/uuidtext/

While similar commands were denied i almost gave up before this one. Now activity monitors permanently went from writing 20MB/s to disk to 0/s bytes.
from 8% cpu for the system to 2%. So while it's a simple solution, there must be little to no reason no to call it a permanent solution. Didn't even use Mac before, but it is UNIX after all.

And even in case it works already, one might not want the moderate log files even. Until after something broke. They might still not be worth wearing down your ssd. (Nor lagging ever for a moment while CPU waits for the SSD, even if it should be rare normally.

if the command responds:
"cp: cannot overwrite directory /private/var/db/uuidtext/dsc with non-directory dsc.", then it didnt run fast enough, so retry until it sais nothing for once and stop there.

BTW sudo fs_usage -w | grep uuidtext only worked once (like crazy and sais resources busy since i canceled the first run.

1

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .