codesigning, the macports user (and other users added by MacPorts) and diskspace (IconServicesAgent) [was Re: lldb ...]
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 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.
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"?
Thanks,
René
PS: this is what afsctool reports about my icon caches
{{{
%> sudo afsctool -cfvv -8 -J4 /var/folders/*/*/C/com.apple.IconServices
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!!
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
python's LINKFORSHARED
Hello pythonXY maintainers,
in python27, the LINKFORSHARED config variable is broken:
$ python2.7 -c "import distutils.sysconfig; \
conf = distutils.sysconfig.get_config_var; \
print (conf('LINKFORSHARED'))"
-u _PyMac_Error Python.framework/Versions/2.7/Python
This value cannot be used for linking. However, this is the exact
command that is used in the current macros in ax_python_devel.m4 from
autoconf-archive [1]. With this value, linking a test program with
python27 will always fail.
All other python ports (really all of python24-26 and python31-36,
except python27) fix the LINKFORSHARED variable with a reinplace in
post-destroot. The very same reinplace existed in the python27 port, but
was removed in r108762:
* remove non-working attempt to change LINKFORSHARED. Any dependents
relying on this are broken anyway and should be fixed to get the
required info from python2.7-config (#39223)
https://trac.macports.org/changeset/108762
https://trac.macports.org/ticket/39223
I don't know what the correct solution would be, but either all python
ports should use the same approach (and have a broken LINKFORSHARED), or
python27 should also do what apparently works for the other ports.
This issue complicates writing ports with +pythonXY variants, as
+python27 needs to be special.
If LINKFORSHARED should really not be used, I would suggest to submit a
patch to autoconf-archive to get it fixed upstream instead of applying
workarounds in individual ports.
Rainer
[1]
http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob;f=m4/ax_python_devel.m4;hb=35f52877a6c1c8568575c2456fb1004e92839a82
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
github desktop's request to install command line tools, and macports git command line tools ...
Github desktop seems a useful tool — but it wants to install command line tools (specifically mentioning github utility and git-lfs) into /usr/local/bin. right now, I’m set up with /opt/local/bin/git and I see there already is a port git-lfs versioned 1.4.1 It’s just these kinds of things that gets things messed up sometimes. Anyone been down this path? Could always install the desktop’s tools and then hide them I suppose ... Ken___ 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
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 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 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 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: github desktop's request to install command line tools, and macports git command line tools ...
> On Sep 18, 2016, at 12:39 PM, Ken Cunningham > wrote: > > Github desktop seems a useful tool — but it wants to install command line > tools (specifically mentioning github utility and git-lfs) into > /usr/local/bin. > > right now, I’m set up with > > /opt/local/bin/git > > and I see there already is a port git-lfs versioned 1.4.1 > > It’s just these kinds of things that gets things messed up sometimes. > > Anyone been down this path? Could always install the desktop’s tools and then > hide them I suppose ... I do use GitHub Desktop. I don't appear to have its command line tools installed. Do you notice missing functionality with GitHub Desktop that you require when those tools are not installed? Otherwise I would say just don't install those tools. But it's probably not the end of the world if you do install the tools. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
