Re: codesigning, the macports user (and other users added by MacPorts) and diskspace (IconServicesAgent) [was Re: lldb ...]
> On Sep 19, 2016, at 04:18, René J.V. Bertin wrote:
>
> On Monday September 19 2016 03:46:32 Jeremy Huddleston Sequoia wrote:
>
>>> TMPDIR points into /var/folders.
>>
>> Yes, and it looks like those do get cleared out on boot.
>>
>> Note, however, that this particular case relates to the cache dir, not tmp
>> (C, not T).
>
> Oh, right, but there are icon caches in both C and T dirs:
>
> {{{
> %> sudo sh -c "du -hcs /var/folders/*/*/*/com.apple.IconServices"
> 81M/var/folders/11/_bf842l54ngf42g66hkzslmwgp/C/com.apple.IconServices
> 264K
> /var/folders/11/_bf842l54ngf42g66hkzslmwgp/T/com.apple.IconServices
> 82M/var/folders/99/yvy25dd94jn_ykbfkf1q4mzwgw/C/com.apple.IconServices
> 88M/var/folders/gf/wmgp2zv506dcsg7_cjxx69m4gr/C/com.apple.IconServices
> 234M
> /var/folders/j1/1439ppj08xj8h6006s6drbq0gs/C/com.apple.IconServices
> 11M/var/folders/j1/1439ppj08xj8h6006s6drbq0gs/T/com.apple.IconServices
> 80M/var/folders/sd/pwbxpphw8xj3vb006s6drbq0gn/C/com.apple.IconServices
> 264K
> /var/folders/sd/pwbxpphw8xj3vb006s6drbq0gn/T/com.apple.IconServices
> 12K/var/folders/zz/zyxvpxvq6csfxvn_n0/C/com.apple.IconServices
> 0B/var/folders/zz/zyxvpxvq6csfxvn_n0/T/com.apple.IconServices
> 12K/var/folders/zz/zyxvpxvq6csfxvn_n0bh2w/C/com.apple.IconServices
> 0B/var/folders/zz/zyxvpxvq6csfxvn_n0bh2w/T/com.apple.IconServices
> 577Mtotal
> }}}
>
> Those are compressed sizes; uncompressed they take about 5.5Gb .
>
>
>>> How large is your own icon cache directory? And asking here is me
>>> investigating. I wouldn't really know where else to ask, Apple's
>>> support/discussions forum? Doesn't seem like the most appropriate place to
>>> discuss this kind of thing :)
>>
>> 6 MB for me. 1MB each for two others.
>
> Right, looks like something isn't right - or something was changed
> significantly since 10.9.
I suspect a change is at least part of it. On 10.9, I see
com.apple.IconServices that contain ISCacheTOC and *.iscachebmp files. On
10.10, I see com.apple.iconservices (notice the case difference) that contains
a single store.index file, and there is a global
/Library/Caches/com.apple.iconservices.store (which is 28 MB on my system).
> I do have a 277Mb large /opt/local/share/icons, but those shouldn't be picked
> up by Apple's IconServices (only a few icon theme directories have ever been
> opened in the Finder, and only by me, not any of the other users with big
> icon caches.
>
> R.
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
smime.p7s
Description: S/MIME cryptographic signature
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: codesigning, the macports user (and other users added by MacPorts) and diskspace (IconServicesAgent) [was Re: lldb ...]
On Monday September 19 2016 03:46:32 Jeremy Huddleston Sequoia wrote:
> > TMPDIR points into /var/folders.
>
> Yes, and it looks like those do get cleared out on boot.
>
> Note, however, that this particular case relates to the cache dir, not tmp
> (C, not T).
Oh, right, but there are icon caches in both C and T dirs:
{{{
%> sudo sh -c "du -hcs /var/folders/*/*/*/com.apple.IconServices"
81M/var/folders/11/_bf842l54ngf42g66hkzslmwgp/C/com.apple.IconServices
264K/var/folders/11/_bf842l54ngf42g66hkzslmwgp/T/com.apple.IconServices
82M/var/folders/99/yvy25dd94jn_ykbfkf1q4mzwgw/C/com.apple.IconServices
88M/var/folders/gf/wmgp2zv506dcsg7_cjxx69m4gr/C/com.apple.IconServices
234M/var/folders/j1/1439ppj08xj8h6006s6drbq0gs/C/com.apple.IconServices
11M/var/folders/j1/1439ppj08xj8h6006s6drbq0gs/T/com.apple.IconServices
80M/var/folders/sd/pwbxpphw8xj3vb006s6drbq0gn/C/com.apple.IconServices
264K/var/folders/sd/pwbxpphw8xj3vb006s6drbq0gn/T/com.apple.IconServices
12K/var/folders/zz/zyxvpxvq6csfxvn_n0/C/com.apple.IconServices
0B/var/folders/zz/zyxvpxvq6csfxvn_n0/T/com.apple.IconServices
12K/var/folders/zz/zyxvpxvq6csfxvn_n0bh2w/C/com.apple.IconServices
0B/var/folders/zz/zyxvpxvq6csfxvn_n0bh2w/T/com.apple.IconServices
577Mtotal
}}}
Those are compressed sizes; uncompressed they take about 5.5Gb .
> > How large is your own icon cache directory? And asking here is me
> > investigating. I wouldn't really know where else to ask, Apple's
> > support/discussions forum? Doesn't seem like the most appropriate place to
> > discuss this kind of thing :)
>
> 6 MB for me. 1MB each for two others.
Right, looks like something isn't right - or something was changed
significantly since 10.9.
I do have a 277Mb large /opt/local/share/icons, but those shouldn't be picked
up by Apple's IconServices (only a few icon theme directories have ever been
opened in the Finder, and only by me, not any of the other users with big icon
caches.
R.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: codesigning, the macports user (and other users added by MacPorts) and diskspace (IconServicesAgent) [was Re: lldb ...]
> On Sep 19, 2016, at 03:31, René J.V. Bertin wrote: > > On Monday September 19 2016 03:02:38 Jeremy Sequoia wrote: > >> /var/tmp definitely isn't cleared though. > > TMPDIR points into /var/folders. Yes, and it looks like those do get cleared out on boot. Note, however, that this particular case relates to the cache dir, not tmp (C, not T). > Here's an example entry from macports's icon cache: > > %> sudo afsctool -vvv > /var/folders/11/_bf842l54ngf42g66hkzslmwgp/C/com.apple.IconServices/FFB06CC518D1C57091BDD19F39A692B6.iscachebmp > > /var/folders/11/_bf842l54ngf42g66hkzslmwgp/C/com.apple.IconServices/FFB06CC518D1C57091BDD19F39A692B6.iscachebmp: > File is HFS+ compressed. > File content type: dyn.age80w65dqfv0u3pcrz2a > File size (uncompressed data fork; reported size by Mac OS 10.6+ Finder): > 4194304 bytes / 4.2 MB (megabytes) / 4 MiB (mebibytes) > File size (compressed data fork - decmpfs xattr; reported size by Mac OS > 10.0-10.5 Finder): 112916 bytes / 115 KB (kilobytes) / 112 KiB (kibibytes) > File size (compressed data fork): 112932 bytes / 115 KB (kilobytes) / 112 KiB > (kibibytes) > Compression savings: 97.3% > Number of extended attributes: 0 > Total size of extended attribute data: 0 bytes > Approximate overhead of extended attributes: 536 bytes > Approximate total file size (compressed data fork + EA + EA overhead + file > overhead): 115488 bytes / 115 KB (kilobytes) / 113 KiB (kibibytes) > > There are a number of files of the same size, plus many smaller. I have no > idea how I can map this to an actual icon though. > > >>> Even if keeping track of who's entitled to access which bits of cached icon >>> info the cache agent could prune the cache, removing everything that hasn't >>> been accessed for more than a reasonably long time. >> >> Again, I think you are seeing something anomalous. You should investigate >> before jumping to conclusions. > > How large is your own icon cache directory? And asking here is me > investigating. I wouldn't really know where else to ask, Apple's > support/discussions forum? Doesn't seem like the most appropriate place to > discuss this kind of thing :) 6 MB for me. 1MB each for two others. # du -scm /private/var/folders/*/*/*/com.apple.iconservices 6 /private/var/folders/c1/7p4m5bx904392j49x1w2vyxhgn/C/com.apple.iconservices 1 /private/var/folders/zz/zyxvpxvq6csfxvn_n0/C/com.apple.iconservices 1 /private/var/folders/zz/zyxvpxvq6csfxvn_n0z07r/C/com.apple.iconservices 6 total smime.p7s Description: S/MIME cryptographic signature ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: codesigning, the macports user (and other users added by MacPorts) and diskspace (IconServicesAgent) [was Re: lldb ...]
On Monday September 19 2016 03:02:38 Jeremy Sequoia wrote: > /var/tmp definitely isn't cleared though. TMPDIR points into /var/folders. Here's an example entry from macports's icon cache: %> sudo afsctool -vvv /var/folders/11/_bf842l54ngf42g66hkzslmwgp/C/com.apple.IconServices/FFB06CC518D1C57091BDD19F39A692B6.iscachebmp /var/folders/11/_bf842l54ngf42g66hkzslmwgp/C/com.apple.IconServices/FFB06CC518D1C57091BDD19F39A692B6.iscachebmp: File is HFS+ compressed. File content type: dyn.age80w65dqfv0u3pcrz2a File size (uncompressed data fork; reported size by Mac OS 10.6+ Finder): 4194304 bytes / 4.2 MB (megabytes) / 4 MiB (mebibytes) File size (compressed data fork - decmpfs xattr; reported size by Mac OS 10.0-10.5 Finder): 112916 bytes / 115 KB (kilobytes) / 112 KiB (kibibytes) File size (compressed data fork): 112932 bytes / 115 KB (kilobytes) / 112 KiB (kibibytes) Compression savings: 97.3% Number of extended attributes: 0 Total size of extended attribute data: 0 bytes Approximate overhead of extended attributes: 536 bytes Approximate total file size (compressed data fork + EA + EA overhead + file overhead): 115488 bytes / 115 KB (kilobytes) / 113 KiB (kibibytes) There are a number of files of the same size, plus many smaller. I have no idea how I can map this to an actual icon though. > > Even if keeping track of who's entitled to access which bits of cached icon > > info the cache agent could prune the cache, removing everything that hasn't > > been accessed for more than a reasonably long time. > > Again, I think you are seeing something anomalous. You should investigate > before jumping to conclusions. How large is your own icon cache directory? And asking here is me investigating. I wouldn't really know where else to ask, Apple's support/discussions forum? Doesn't seem like the most appropriate place to discuss this kind of thing :) R ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: codesigning, the macports user (and other users added by MacPorts) and diskspace (IconServicesAgent) [was Re: lldb ...]
Sent from my iPhone... > On Sep 19, 2016, at 02:52, René J.V. Bertin wrote: > > On Monday September 19 2016 02:08:12 Jeremy Huddleston Sequoia wrote: > >>> The icon cache sits in the user's $TMPDIR, and AFAIK that directory is >>> emptied at boot. >> >> No. /tmp is emptied at boot, not /var/tmp and not /var/folders. > > Did that change after 10.9? I keep a Finder window open on $TMPDIR on one of > my "Spaces", and it's always empty after logging in to a new session (which I > only do after rebooting). I could just be wrong. I'll double check tomorrow. /var/tmp definitely isn't cleared though. >> Well, if you're able to update to 10.10+, launchd2 is much much nicer at >> helping triage such things... > > At some point I guess I will... (have to...) > >> There are ACL settings somewhere to control that. It's not based on uid. I >> don't recall what it is off the top of my head. > > OK, great, let me know if anything comes to mind that could help me in a > google search. > >>> , and when? Boot time? Or login, and if so, what kind of login? >> >> The user (background) session is created whenever the user does pretty much >> anything (ssh, cron, sudo -u, screen sharing, etc.). >> The gui (aqua) session is created wheneger the user logs in to the gui >> (screen sharing, console, etc). >> > > And the gui session is never taken down when the user logs of the gui? It is at some point. > Should one think of launchd as the equivalent of Linux's systemd, or does it > also have bits of DBus? Similar in concept I suppose but quite different in practice. I'd take launchd over DBus and systemd any time. > >> iconservicesagent processes? 2, one in the system domain and one in my >> user's aqua session: >> $ ps aux | grep iconservicesagent >> jeremy677 0.0 0.1 2918544 19908 ?? SMon09AM >> 0:08.85 /System/Library/CoreServices/iconservicesagent >> root 92 0.0 0.0 2516172492 ?? Ss Mon09AM >> 0:00.47 /System/Library/CoreServices/iconservicesagent >> > > How large is root's icon cache? Do you have any idea why the agent is running > for root? Because of the login manager, maybe? It's in the system session, not root's user session. That's the LaunchDaemon. >> Yes. That's a clear privacy violation. User A could use that to determine >> what applications User B has installed. If there happened to be some kind >> of image rendering exploit, User A could install an app private to them to >> cause User B to render compromised icons. Etc, etc, etc. > > And you're seriously thinking that user A couldn't figure that out otherwise, > like from looking at the output from ps (running ps in a cron job because > evidently no 2 users can be logged in to the gui at the same time). ps would only tell you what is running, not what is installed. User B should also not have their icon sets changes just because User A downloaded some. ew app. > Even if keeping track of who's entitled to access which bits of cached icon > info the cache agent could prune the cache, removing everything that hasn't > been accessed for more than a reasonably long time. Again, I think you are seeing something anomalous. You should investigate before jumping to conclusions. >> Have you looked at the cache to see exactly what the icons are that are >> taking up so much room? I suspect that might give you a clue as to how >> they're getting there in the first place. > > Well, I did take a look, but there' a LOT of files in there, and they all > seem to be quite small. That's backed up by the percentages in brackets from > afsctool; those are CPU loads. With 4 threads that should approach 400% if > there were only large files; the smaller the number, the more time the > algorithm spends waiting for I/O instead of compressing data. > > R. > > PS: > Aqua, seriously? Is that term still being used or is it just a hardcoded > string in a couple of places that was never changed? Because there isn't much > left of the original watery appearance; possibly only the default > selection/highlight colour ... :) ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: codesigning, the macports user (and other users added by MacPorts) and diskspace (IconServicesAgent) [was Re: lldb ...]
On Monday September 19 2016 02:08:12 Jeremy Huddleston Sequoia wrote: >> The icon cache sits in the user's $TMPDIR, and AFAIK that directory is >> emptied at boot. > >No. /tmp is emptied at boot, not /var/tmp and not /var/folders. Did that change after 10.9? I keep a Finder window open on $TMPDIR on one of my "Spaces", and it's always empty after logging in to a new session (which I only do after rebooting). >Well, if you're able to update to 10.10+, launchd2 is much much nicer at >helping triage such things... At some point I guess I will... (have to...) >There are ACL settings somewhere to control that. It's not based on uid. I >don't recall what it is off the top of my head. OK, great, let me know if anything comes to mind that could help me in a google search. >> , and when? Boot time? Or login, and if so, what kind of login? > >The user (background) session is created whenever the user does pretty much >anything (ssh, cron, sudo -u, screen sharing, etc.). >The gui (aqua) session is created wheneger the user logs in to the gui (screen >sharing, console, etc). > And the gui session is never taken down when the user logs of the gui? Should one think of launchd as the equivalent of Linux's systemd, or does it also have bits of DBus? >iconservicesagent processes? 2, one in the system domain and one in my user's >aqua session: >$ ps aux | grep iconservicesagent >jeremy677 0.0 0.1 2918544 19908 ?? SMon09AM 0:08.85 >/System/Library/CoreServices/iconservicesagent >root 92 0.0 0.0 2516172492 ?? Ss Mon09AM 0:00.47 >/System/Library/CoreServices/iconservicesagent > How large is root's icon cache? Do you have any idea why the agent is running for root? Because of the login manager, maybe? >Yes. That's a clear privacy violation. User A could use that to determine >what applications User B has installed. If there happened to be some kind of >image rendering exploit, User A could install an app private to them to cause >User B to render compromised icons. Etc, etc, etc. And you're seriously thinking that user A couldn't figure that out otherwise, like from looking at the output from ps (running ps in a cron job because evidently no 2 users can be logged in to the gui at the same time). Even if keeping track of who's entitled to access which bits of cached icon info the cache agent could prune the cache, removing everything that hasn't been accessed for more than a reasonably long time. >Have you looked at the cache to see exactly what the icons are that are taking >up so much room? I suspect that might give you a clue as to how they're >getting there in the first place. Well, I did take a look, but there' a LOT of files in there, and they all seem to be quite small. That's backed up by the percentages in brackets from afsctool; those are CPU loads. With 4 threads that should approach 400% if there were only large files; the smaller the number, the more time the algorithm spends waiting for I/O instead of compressing data. R. PS: Aqua, seriously? Is that term still being used or is it just a hardcoded string in a couple of places that was never changed? Because there isn't much left of the original watery appearance; possibly only the default selection/highlight colour ... :) ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: codesigning, the macports user (and other users added by MacPorts) and diskspace (IconServicesAgent) [was Re: lldb ...]
> On Sep 19, 2016, at 00:34, René J.V. Bertin wrote: > > On Sunday September 18 2016 19:23:01 Jeremy Huddleston Sequoia wrote: > Yes, of course it's possible. Don't. There's nothing special about the UID in this case that has anything to do with what you're seeing. >>> >>> So what does make the difference? >> >> What is "the difference" that you want? All users have a user session, and >> if logged in to the gui, they also have an aqua (gui) session. All users. > > As I said, there's an order of magnitude difference in the size of the icon > cache for users like root, and that of users like macports or ldap. Well, that has nothing to do with the username or uid. It has to do with what the user is doing. > The icon cache sits in the user's $TMPDIR, and AFAIK that directory is > emptied at boot. No. /tmp is emptied at boot, not /var/tmp and not /var/folders. > My machine has been up for 35 days, and in that time I certainly didn't log > any of the "incriminated" users into an aqua session. Well, if you're able to update to 10.10+, launchd2 is much much nicer at helping triage such things... > I did things as the macports user that could explain why an IconServiceAgent > was started for it, but that's it. FWIW, I removed the entries for a few > other users before reporting here, including avahi - those haven't come back > yet. > > A difference I could think of is a setting that tells the system not to let a > particular user log in to a gui session. > Which is why I thought of a UID<500; those at least don't show up in the > login manager. But maybe they can still be logged in if the login manager is > in traditional text (= no icon) mode? There are ACL settings somewhere to control that. It's not based on uid. I don't recall what it is off the top of my head. >>> Possibly a tool, but what could have that effect? AFAIK the icon cache is >>> chiefly used by the Finder, so anything that leverages the Finder might >>> cause an icon cache to be populated. >> >> It's marked as RunAtLoad on my system (Sierra). That would explain why it's >> running, even if nothing needs it... > > But RunAtLoad for whom For all users. > , and when? Boot time? Or login, and if so, what kind of login? The user (background) session is created whenever the user does pretty much anything (ssh, cron, sudo -u, screen sharing, etc.). The gui (aqua) session is created wheneger the user logs in to the gui (screen sharing, console, etc). > How many copies do you have running now? Of what? User domains? 11: $ launchctl print system | grep com.apple.xpc.launchd.domain.user com.apple.xpc.launchd.domain.user.235 com.apple.xpc.launchd.domain.user.502 com.apple.xpc.launchd.domain.user.200 com.apple.xpc.launchd.domain.user.260 com.apple.xpc.launchd.domain.user.55 com.apple.xpc.launchd.domain.user.92 com.apple.xpc.launchd.domain.user.501 com.apple.xpc.launchd.domain.user.212 com.apple.xpc.launchd.domain.user.89 com.apple.xpc.launchd.domain.user.202 com.apple.xpc.launchd.domain.user.0 iconservicesagent processes? 2, one in the system domain and one in my user's aqua session: $ ps aux | grep iconservicesagent jeremy677 0.0 0.1 2918544 19908 ?? SMon09AM 0:08.85 /System/Library/CoreServices/iconservicesagent root 92 0.0 0.0 2516172492 ?? Ss Mon09AM 0:00.47 /System/Library/CoreServices/iconservicesagent > What surprises me is that every user would have to need a personal icon cache > for every icon in the system. > I know user A could have an app installed with a doc type having a particular > icon that no other user on the system is likely to encounter, but would it > hurt if they did get to see the icon if they stumbled across such a document? > IOW, would it be bad if all file-to-icon associations were cached in a > central location, 1 copy for everyone? Yes. That's a clear privacy violation. User A could use that to determine what applications User B has installed. If there happened to be some kind of image rendering exploit, User A could install an app private to them to cause User B to render compromised icons. Etc, etc, etc. > Not only does that cache get big, it also consists of plenty of small files, > which makes its actual footprint on disk even larger (due to blocksize; I > think that hasn't changed with SSDs?). Have you looked at the cache to see exactly what the icons are that are taking up so much room? I suspect that might give you a clue as to how they're getting there in the first place. smime.p7s Description: S/MIME cryptographic signature ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: codesigning, the macports user (and other users added by MacPorts) and diskspace (IconServicesAgent) [was Re: lldb ...]
On Sunday September 18 2016 19:23:01 Jeremy Huddleston Sequoia wrote: >>> Yes, of course it's possible. Don't. There's nothing special about the >>> UID in this case that has anything to do with what you're seeing. >> >> So what does make the difference? > >What is "the difference" that you want? All users have a user session, and if >logged in to the gui, they also have an aqua (gui) session. All users. As I said, there's an order of magnitude difference in the size of the icon cache for users like root, and that of users like macports or ldap. The icon cache sits in the user's $TMPDIR, and AFAIK that directory is emptied at boot. My machine has been up for 35 days, and in that time I certainly didn't log any of the "incriminated" users into an aqua session. I did things as the macports user that could explain why an IconServiceAgent was started for it, but that's it. FWIW, I removed the entries for a few other users before reporting here, including avahi - those haven't come back yet. A difference I could think of is a setting that tells the system not to let a particular user log in to a gui session. Which is why I thought of a UID<500; those at least don't show up in the login manager. But maybe they can still be logged in if the login manager is in traditional text (= no icon) mode? >> Possibly a tool, but what could have that effect? AFAIK the icon cache is >> chiefly used by the Finder, so anything that leverages the Finder might >> cause an icon cache to be populated. > >It's marked as RunAtLoad on my system (Sierra). That would explain why it's >running, even if nothing needs it... But RunAtLoad for whom, and when? Boot time? Or login, and if so, what kind of login? How many copies do you have running now? What surprises me is that every user would have to need a personal icon cache for every icon in the system. I know user A could have an app installed with a doc type having a particular icon that no other user on the system is likely to encounter, but would it hurt if they did get to see the icon if they stumbled across such a document? IOW, would it be bad if all file-to-icon associations were cached in a central location, 1 copy for everyone? Not only does that cache get big, it also consists of plenty of small files, which makes its actual footprint on disk even larger (due to blocksize; I think that hasn't changed with SSDs?). R. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: codesigning, the macports user (and other users added by MacPorts) and diskspace (IconServicesAgent) [was Re: lldb ...]
> On Sep 18, 2016, at 18:10, René J.V. Bertin wrote: > > On Sunday September 18 2016 17:24:55 Jeremy Huddleston Sequoia wrote: > >> That all looks as expected for someone on OS X 10.9. launchd2 in 10.10+ did >> away with per-user launchd. All domains are managed by the same process. > > Still, why would a background user without even an interactive shell be > running an IconServicesAgent? >> >> That's pretty large. I'm a bit surprised by that. >> >> My macports user's disk usage is about 90 MB, mostly for its pch cache. > > That fits with the size I'm seeing for root and _securityagent. 900Mb is > about what I see for users who have logged in at some point. > >>> Is it possible to create users with UID<500 despite those numbers being >>> "reserved by Apple"? >> >> Yes, of course it's possible. Don't. There's nothing special about the UID >> in this case that has anything to do with what you're seeing. > > So what does make the difference? What is "the difference" that you want? All users have a user session, and if logged in to the gui, they also have an aqua (gui) session. All users. > > >>> %> sudo afsctool -cfvv -8 -J4 /var/folders/*/*/C/com.apple.IconServices >> >> What is -J4? I don't see that option mentioned, and afsctool seems to bawk >> at it. > > That's an option from my parallel version: > https://github.com/RJVB/afsctool > > I think I'll have to set up a cron task or similar that runs the afsctool > command with an appropriate frequency. Since the run from this morning only > my own icon cache has increased to about 250Mb; still 1/4 or what it was > before compressing. > >> On Sunday September 18 2016 20:42:53 Brandon Allbery wrote: Some port somewhere likely builds the icon cache while building or "installing" (destrooting) since it "knows" that it would only be built by the person intending to use it and that nobody uses packaging on OS X. :/ >>> >>> ...or maybe some tool invoked during build. The former could be mitigated; >>> the latter may be harder. > > Possibly a tool, but what could have that effect? AFAIK the icon cache is > chiefly used by the Finder, so anything that leverages the Finder might cause > an icon cache to be populated. It's marked as RunAtLoad on my system (Sierra). That would explain why it's running, even if nothing needs it... > But come to think of it that cannot be my case; the non-privileged build > phases are run under my own ID on my system. > > I'm calling it a night for now ... > > R. > ___ > macports-dev mailing list > macports-dev@lists.macosforge.org > https://lists.macosforge.org/mailman/listinfo/macports-dev smime.p7s Description: S/MIME cryptographic signature ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: codesigning, the macports user (and other users added by MacPorts) and diskspace (IconServicesAgent) [was Re: lldb ...]
On Sunday September 18 2016 17:24:55 Jeremy Huddleston Sequoia wrote: > That all looks as expected for someone on OS X 10.9. launchd2 in 10.10+ did > away with per-user launchd. All domains are managed by the same process. Still, why would a background user without even an interactive shell be running an IconServicesAgent? > > That's pretty large. I'm a bit surprised by that. > > My macports user's disk usage is about 90 MB, mostly for its pch cache. That fits with the size I'm seeing for root and _securityagent. 900Mb is about what I see for users who have logged in at some point. > > Is it possible to create users with UID<500 despite those numbers being > > "reserved by Apple"? > > Yes, of course it's possible. Don't. There's nothing special about the UID > in this case that has anything to do with what you're seeing. So what does make the difference? > > %> sudo afsctool -cfvv -8 -J4 /var/folders/*/*/C/com.apple.IconServices > > What is -J4? I don't see that option mentioned, and afsctool seems to bawk > at it. That's an option from my parallel version: https://github.com/RJVB/afsctool I think I'll have to set up a cron task or similar that runs the afsctool command with an appropriate frequency. Since the run from this morning only my own icon cache has increased to about 250Mb; still 1/4 or what it was before compressing. > On Sunday September 18 2016 20:42:53 Brandon Allbery wrote: > > > Some port somewhere likely builds the icon cache while building or > > > "installing" (destrooting) since it "knows" that it would only be built > > > by > > > the person intending to use it and that nobody uses packaging on OS X. > > > :/ > > > > ...or maybe some tool invoked during build. The former could be mitigated; > > the latter may be harder. Possibly a tool, but what could have that effect? AFAIK the icon cache is chiefly used by the Finder, so anything that leverages the Finder might cause an icon cache to be populated. But come to think of it that cannot be my case; the non-privileged build phases are run under my own ID on my system. I'm calling it a night for now ... R. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: codesigning, the macports user (and other users added by MacPorts) and diskspace (IconServicesAgent) [was Re: lldb ...]
On Sun, Sep 18, 2016 at 8:41 PM, Brandon Allbery wrote: > Some port somewhere likely builds the icon cache while building or > "installing" (destrooting) since it "knows" that it would only be built by > the person intending to use it and that nobody uses packaging on OS X. :/ ...or maybe some tool invoked during build. The former could be mitigated; the latter may be harder. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: codesigning, the macports user (and other users added by MacPorts) and diskspace (IconServicesAgent) [was Re: lldb ...]
On Sun, Sep 18, 2016 at 8:24 PM, Jeremy Huddleston Sequoia < jerem...@apple.com> wrote: > > Anyway, I don't see any valid reason why the macports user would have a > fullblown icon cache. In my case each cache directory eats up about 900Mb. > Some may find that insignificant; I still consider it a waste of space. > > That's pretty large. I'm a bit surprised by that. Some port somewhere likely builds the icon cache while building or "installing" (destrooting) since it "knows" that it would only be built by the person intending to use it and that nobody uses packaging on OS X. :/ -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: codesigning, the macports user (and other users added by MacPorts) and diskspace (IconServicesAgent) [was Re: lldb ...]
> On Sep 18, 2016, at 04:25, René J.V. Bertin wrote:
>
> Hi,
>
> This isn't actually about codesigning but something that may have come up
> because of my testing in that domain.
>
> I got a low disk space warning (for an unrelated reason) and hunting down the
> space eater I noticed this:
>
> {{{
> %> id macports
> uid=502(macports) gid=503(macports)
> groups=503(macports),12(everyone),61(localaccounts),402(com.apple.sharepoint.group.1),403(com.apple.sharepoint.group.2),100(_lpoperator)
> %> ps -u 502
> UID PID TTY TIME CMD
> 502 1476 ?? 0:26.85 /sbin/launchd
> 502 1479 ?? 0:19.00 /usr/sbin/distnoted agent
> 502 3843 ?? 0:00.14 /usr/libexec/xpcd
> 502 3844 ?? 0:13.81 com.apple.IconServicesAgent
> 502 94723 ?? 0:00.06
> /System/Library/Frameworks/CoreServices.framework/Frameworks/Metadata.framework/Versions/A/Support/md
> 502 95293 ?? 0:00.19 /usr/sbin/cfprefsd agent
> }}}
>
> I'm not sure if it's normal that macports has a launchd running
That all looks as expected for someone on OS X 10.9. launchd2 in 10.10+ did
away with per-user launchd. All domains are managed by the same process.
> or to what extent that has to do with my recent tests of using that user's
> keychain for codesigning. I started the Keychain Utility as user macports,
> maybe that's what launched launchd c.s.
> Anyway, I don't see any valid reason why the macports user would have a
> fullblown icon cache. In my case each cache directory eats up about 900Mb.
> Some may find that insignificant; I still consider it a waste of space.
That's pretty large. I'm a bit surprised by that.
My macports user's disk usage is about 90 MB, mostly for its pch cache.
> I also notice that users like root and _securityagent have *much* smaller
> icon cache directories. Does anyone know if there's a setting or other means
> to limit the information being cached by users that should never run
> full-blown sessions? Could it be related to the UID being larger or smaller
> than some symbolic value (often 500 on Unix)?
>
> Evidently the macports user isn't the only one that's concerned: any user
> added by MacPorts is (polkituser, polkitd, avahi, ldap, ...)
>
> Is it possible to create users with UID<500 despite those numbers being
> "reserved by Apple"?
Yes, of course it's possible. Don't. There's nothing special about the UID in
this case that has anything to do with what you're seeing.
>
> Thanks,
> René
>
> PS: this is what afsctool reports about my icon caches
> {{{
> %> sudo afsctool -cfvv -8 -J4 /var/folders/*/*/C/com.apple.IconServices
What is -J4? I don't see that option mentioned, and afsctool seems to bawk at
it.
> Adding
> /var/folders/11/_bf842l54ngf42g66hkzslmwgp/C/com.apple.IconServices to
> queue
> Adding
> /var/folders/8d/5ghf31k1063f1wcln60nd91hgv/C/com.apple.IconServices to
> queue
> Adding
> /var/folders/99/yvy25dd94jn_ykbfkf1q4mzwgw/C/com.apple.IconServices to
> queue
> Adding
> /var/folders/gf/wmgp2zv506dcsg7_cjxx69m4gr/C/com.apple.IconServices to
> queue
> Adding
> /var/folders/j1/1439ppj08xj8h6006s6drbq0gs/C/com.apple.IconServices to
> queue
> Adding
> /var/folders/sd/pwbxpphw8xj3vb006s6drbq0gn/C/com.apple.IconServices to
> queue
> Adding
> /var/folders/zz/zyxvpxvq6csfxvn_n0/C/com.apple.IconServices to
> queue
> Adding
> /var/folders/zz/zyxvpxvq6csfxvn_n0bh2w/C/com.apple.IconServices to
> queue
> Starting 4 worker threads to process queue with 8617 items
> 11% [33.45%] .. 21% [33.95%] .. 32% [33.63%] .. 42% [31.99%] .. 52% [30.15%]
> .. 63% [29.08%] .. 73% [27.90%] .. 84% [27.30%] .. 94% [27.62%]
> Processed 8617 entries
> Total number of files: 14016
> Total number of file hard links: 0
> Total number of folders: 0
> Total number of folder hard links: 0
> Total number of items (number of files + number of folders): 14016
> Folder size (uncompressed; reported size by Mac OS 10.6+ Finder): 6306042064
> bytes / 6.32 GB (gigabytes) / 5.88 GiB (gibibytes)
> Folder size (compressed - decmpfs xattr; reported size by Mac OS 10.0-10.5
> Finder): 665214917 bytes / 678.6 MB (megabytes) / 647.2 MiB (mebibytes)
> Folder size (compressed): 676008333 bytes / 689.4 MB (megabytes) / 657.5 MiB
> (mebibytes)
> Compression savings: 89.3%
> Approximate total folder size (files + file overhead + folder overhead):
> 698299808 bytes / 698.3 MB (megabytes) / 666 MiB (mebibytes)
> }}}
>
> IOW, they compress about 10x. A real shame HFS doesn't have transparent,
> online compression!!
smime.p7s
Description: S/MIME cryptographic signature
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
