[OpenIndiana-discuss] SOLVED: MATE 1.20 and updated GTK+3 for hipster
Predrag Zečević - Technical Support Analyst
predrag.zecevic at 2e-systems.com
Wed Oct 24 12:37:57 UTC 2018
On 10/24/18 13:51, Udo Grabowski (IMK) wrote:
> On 24/10/2018 12:54, Predrag Zečević - Technical Support Analyst wrote:
>> On 10/24/18 12:42, Predrag Zečević - Technical Support Analyst wrote:
>>> On 10/24/18 12:07, Udo Grabowski (IMK) wrote:
>>>> On 24/10/2018 09:09, Predrag Zečević - Technical Support Analyst wrote:
>>>>> On 10/23/18 21:42, Alan Coopersmith wrote:
>>>>>> On 10/23/18 07:38 AM, Predrag Zečević - Technical Support Analyst
>>>>>> wrote:
>>>>>>> What I wanted to say is, if desktop relies heavily of ownership
>>>>>>> (???) of
>>>>>>> directory /var/cache/fontconfig, maybe that package has to check it
>>>>>>> (pkg
>>>>>>> verify?)
>>>>>>
>>>>>> IPS packages are just data, they can't run commands like pkg verify -
>>>>>> unlike
>>>>>> other package systems, there is no scripting.
>>>>>>
>>>>>> The closest that could happen would be adding it to the fc-cache
>>>>>> service -
>>>>>> packages that deliver fonts trigger a refresh of this service to
>>>>>> update the
>>>>>> caches.
>>>>>>
>>>>>
>>>>> I still do not understand why this:
>>>>> $ find /var/cache/fontconfig/ -type f | wc -l
>>>>> 32766
>>>>>
>>>>> That is simply too much!
>>>>>
>>>>> $ pkg verify pkg:/system/library/fontconfig
>>>>> [Returns nothing]
>>>>>
>>>>> $ pkg fix pkg:/system/library/fontconfig
>>>>> No updates necessary for this image.
>>>>>
>>>>> That is not too much in size, though:
>>>>> $ du -shc /var/cache/fontconfig/
>>>>> 44M /var/cache/fontconfig/
>>>>> 44M total
>>>>>
>>>>>
>>>>> Can someone share his /var/cache/fontconfig/ details (on desktop,
>>>>> using
>>>>> OI /hipster)? Just to compare ...
>>>>>
>>>>
>>>> Just for reference: A (fontwise) well equipped OI_151a9 has between
>>>> 150 and 200 files with about 9-11 MB contents. The hipster server
>>>> without Mate actively running has 11MB and 175 files. A second
>>>> older hipster server without Mate usage is at 200 files and 5 MB.
>>>>
>>>> Maybe the high number comes from the fact that it just repeatedly
>>>> renewed the caches ? Does it still fill up to that number if you
>>>> remove all those cachefiles ?
>>>
>>> Right now ("beast" grows):
>>> $ find /var/cache/fontconfig/ -type f | wc -l
>>> 119050
>>>
>>> $ du -shc /var/cache/fontconfig/
>>> 140M /var/cache/fontconfig/
>>>
>>> I will stop font cache; remove files; fix package (if that is still
>>> valid); start font cache.
>>>
>>> expect my comeback, with some details, after some monitoring time
>>> again...
>>>
>>> With best regards.
>>> Predrag Zečević
>>>
>>
>> $ pfexec svcadm disable svc:/application/font/fc-cache:default
>> $ pfexec rm -rf /var/cache/fontconfig
>> $ pkg fix pkg:/system/library/fontconfig
>> ### This has created missing dir, and while fc-cache is disabled:
>> $ find /var/cache/fontconfig/ -type f | wc -l
>> 571
>>
>> ### 5 minutes later:
>> $ svcs -H svc:/application/font/fc-cache:default
>> disabled 12:44:31 svc:/application/font/fc-cache:default
>>
>> $ find /var/cache/fontconfig/ -type f | wc -l
>> 1525
>>
>> ### ???
>>
>> ### Permissions:
>> $ ls -ald /var/cache/fontconfig
>> drwxr-xr-x 2 root bin 2,4K Oct 24 12:51 /var/cache/fontconfig
>>
>> ### but:
>> $ ls -ald
>> /var/cache/fontconfig/ffe26a2d-c157-e025-f064-ef404833b1af-le32d4.cache-7
>> -rw-r--r-- 1 predrag_zecevic admin 104 Oct 24 12:47
>> /var/cache/fontconfig/ffe26a2d-c157-e025-f064-ef404833b1af-le32d4.cache-7
>>
>> Looks like some process is filling in that directory (not fc-cache)...
>>
>> Is it possible to "watch" directory for updates (to get process filling
>> it in)?
>>
>> With best regards.
>>
>
> From Brendan Greggs Dtrace Toolkit, here's the fsrw.d script
> (I think the pid should be accessible at (curthread->t_procp).pr_pid ):
>
> #!/usr/sbin/dtrace -s
> /*
> * fsrw.d - file system read/write event tracing.
> * Written using DTrace (Solaris 10 3/05)
> *
> * This traces file related activity: system call reads and writes,
> * vnode logical read and writes (fop), and disk I/O. It can be used
> * to examine the behaviour of each I/O layer, from the syscall
> * interface to what the disk is doing. Behaviour such as read-ahead, and
> * max I/O size breakup can be observed.
> *
> * $Id: fsrw.d 3 2007-08-01 10:50:08Z brendan $
> *
> * USAGE: fsrw.d
> *
> * FIELDS:
> * Event Traced event (see EVENTS below)
> * Device Device, for disk I/O
> * RW Either Read or Write
> * Size Size of I/O in bytes
> * Offset Offset of I/O in kilobytes
> * Path Path to file on disk
> *
> * EVENTS:
> * sc-read System call read
> * sc-write System call write
> * fop_read Logical read
> * fop_write Logical write
> * disk_io Physical disk I/O
> * disk_ra Physical disk I/O, read ahead
> *
> * The events are drawn with a level of indentation, which can sometimes
> * help identify related events.
> *
> * SEE ALSO: fspaging.d
> *
> * IDEA: Richard McDougall, Solaris Internals 2nd Ed, FS Chapter.
> *
> * COPYRIGHT: Copyright (c) 2006 Brendan Gregg.
> *
> * CDDL HEADER START
> *
> * The contents of this file are subject to the terms of the
> * Common Development and Distribution License, Version 1.0 only
> * (the "License"). You may not use this file except in compliance
> * with the License.
> *
> * You can obtain a copy of the license at Docs/cddl1.txt
> * or http://www.opensolaris.org/os/licensing.
> * See the License for the specific language governing permissions
> * and limitations under the License.
> *
> * CDDL HEADER END
> *
> * ToDo: readv()
> *
> * 20-Mar-2006 Brendan Gregg Created this.
> * 23-Apr-2006 " " Last update.
> */
>
> #pragma D option quiet
> #pragma D option switchrate=10hz
>
> dtrace:::BEGIN
> {
> printf("%-12s %10s %2s %8s %6s %s\n",
> "Event", "Device", "RW", "Size", "Offset", "Path");
> }
>
> syscall::*read:entry,
> syscall::*write*:entry
> {
> /*
> * starting with a file descriptior, dig out useful info
> * from the corresponding file_t and vnode_t.
> */
> this->filistp = curthread->t_procp->p_user.u_finfo.fi_list;
> this->ufentryp = (uf_entry_t *)((uint64_t)this->filistp +
> (uint64_t)arg0 * (uint64_t)sizeof (uf_entry_t));
> this->filep = this->ufentryp->uf_file;
> self->offset = this->filep->f_offset;
> this->vnodep = this->filep != 0 ? this->filep->f_vnode : 0;
> self->vpath = this->vnodep ? (this->vnodep->v_path != 0 ?
> cleanpath(this->vnodep->v_path) : "<unknown>") : "<unknown>";
>
> /* only trace activity to regular files and directories, as */
> self->sc_trace = this->vnodep ? this->vnodep->v_type == VREG ||
> this->vnodep->v_type == VDIR ? 1 : 0 : 0;
> }
>
> syscall::*read:entry
> /self->sc_trace/
> {
> printf("sc-%-9s %10s %2s %8d %6d %s\n", probefunc, ".", "R",
> (int)arg2, self->offset / 1024, self->vpath);
> }
>
> syscall::*write*:entry
> /self->sc_trace/
> {
> printf("sc-%-9s %10s %2s %8d %6d %s\n", probefunc, ".", "W",
> (int)arg2, self->offset / 1024, self->vpath);
> }
>
> syscall::*read:return,
> syscall::*write*:return
> {
> self->vpath = 0;
> self->offset = 0;
> self->sc_trace = 0;
> }
>
> fbt::fop_read:entry,
> fbt::fop_write:entry
> /self->sc_trace && args[0]->v_path/
> {
> printf(" %-10s %10s %2s %8d %6d %s\n", probefunc, ".",
> probefunc == "fop_read" ? "R" : "W", args[1]->uio_resid,
> args[1]->_uio_offset._f / 1024, cleanpath(args[0]->v_path));
> }
>
> fbt:ufs:ufs_getpage_ra:entry
> {
> /* fetch the real offset (file_t is unaware of this) */
> self->ra_offset = ((inode_t *)args[0]->v_data)->i_nextrio;
> self->read_ahead = 1;
> }
>
> fbt:ufs:ufs_getpage_ra:return
> {
> self->read_ahead = 0;
> self->ra_offset = 0;
> }
>
> io::bdev_strategy:start
> {
> this->offset = self->read_ahead ? self->ra_offset :
> args[2]->fi_offset;
> printf(" %-8s %10s %2s %8d %6d %s\n",
> self->read_ahead ? "disk_ra" : "disk_io",
> args[1]->dev_statname,
> args[0]->b_flags & B_READ ? "R" : "W", args[0]->b_bcount,
> this->offset / 1024, args[2]->fi_pathname);
> /*
> * it would seem to make sense to only trace disk events during
> * an fop event, easily coded with a self->fop_trace flag. However
> * writes are asynchronous to the fop_write calls (they are flushed
> * at some later time), and so this approach will miss tracing
> * most of the disk writes.
> */
> }
>
I was running it for 10 minutes:
$ /opt/DTT/Bin/fsrw.d |& tee /tmp/fsrw.out
And here, only small part:
$ grep fontconfig /tmp/fsrw.out | head -20
sc-read . R 144 0
/var/cache/fontconfig/4984924f-cb2b-4f56-83f9-d6ed049c5211-le32d4.cache-7
fop_read . R 144 0
/var/cache/fontconfig/4984924f-cb2b-4f56-83f9-d6ed049c5211-le32d4.cache-7
sc-read . R 224 0
/var/cache/fontconfig/91f19950-06de-e4b2-c308-af2c76c9ab4c-le32d4.cache-7
fop_read . R 224 0
/var/cache/fontconfig/91f19950-06de-e4b2-c308-af2c76c9ab4c-le32d4.cache-7
sc-write . W 5 0
/var/cache/fontconfig/a43adf73-7ab2-67f0-d259-c0c16712c25b-le32d4.cache-7.TMP-4RHWMm
fop_write . W 5 0
/var/cache/fontconfig/a43adf73-7ab2-67f0-d259-c0c16712c25b-le32d4.cache-7.TMP-4RHWMm
sc-write . W 104 0
/var/cache/fontconfig/a43adf73-7ab2-67f0-d259-c0c16712c25b-le32d4.cache-7.NEW
fop_write . W 104 0
/var/cache/fontconfig/a43adf73-7ab2-67f0-d259-c0c16712c25b-le32d4.cache-7.NEW
sc-write . W 5 0
/var/cache/fontconfig/23e0cdd1-48f2-c273-e267-94de98aaeb6d-le32d4.cache-7.TMP-6RHWMm
fop_write . W 5 0
/var/cache/fontconfig/23e0cdd1-48f2-c273-e267-94de98aaeb6d-le32d4.cache-7.TMP-6RHWMm
sc-write . W 112 0
/var/cache/fontconfig/23e0cdd1-48f2-c273-e267-94de98aaeb6d-le32d4.cache-7.NEW
fop_write . W 112 0
/var/cache/fontconfig/23e0cdd1-48f2-c273-e267-94de98aaeb6d-le32d4.cache-7.NEW
sc-write . W 5 0
/var/cache/fontconfig/2c045bf7-5fbd-45f5-90eb-b050152db220-le32d4.cache-7.TMP-8RHWMm
fop_write . W 5 0
/var/cache/fontconfig/2c045bf7-5fbd-45f5-90eb-b050152db220-le32d4.cache-7.TMP-8RHWMm
sc-write . W 104 0
/var/cache/fontconfig/2c045bf7-5fbd-45f5-90eb-b050152db220-le32d4.cache-7.NEW
fop_write . W 104 0
/var/cache/fontconfig/2c045bf7-5fbd-45f5-90eb-b050152db220-le32d4.cache-7.NEW
sc-write . W 5 0
/var/cache/fontconfig/73afedac-03f0-649d-cc6a-f110b80e1d91-le32d4.cache-7.TMP-.RHWMm
fop_write . W 5 0
/var/cache/fontconfig/73afedac-03f0-649d-cc6a-f110b80e1d91-le32d4.cache-7.TMP-.RHWMm
sc-write . W 112 0
/var/cache/fontconfig/73afedac-03f0-649d-cc6a-f110b80e1d91-le32d4.cache-7.NEW
fop_write . W 112 0
/var/cache/fontconfig/73afedac-03f0-649d-cc6a-f110b80e1d91-le32d4.cache-7.NEW
Cache is constantly rebuilt (do not have so much fonts installed, looks
like something misses cache, and creates now one), but not sure which
process does it...
Right now:
$ find /var/cache/fontconfig/ -type f | wc -l
41633
$ du -shc /var/cache/fontconfig/
53M /var/cache/fontconfig/
Thanks anyway.
With best regards.
Predrag Zečević
--
Predrag Zečević
Technical Support Analyst
2e Systems GmbH
tel: +49 - 6196 - 95058 - 15
mob: +49 - 174 - 3109288
fax: +49 - 6196 - 95058 - 94
e-mail: predrag.zecevic at 2e-systems.com
headquarter: 2e Systems GmbH, Koenigsteiner Str. 87, 65812 Bad Soden am
Taunus, Germany
registration: Amtsgericht Koenigstein (Germany), HRB 7303
managing director: Phil Douglas
http://www.2e-systems.com/ - Making your business fly!
More information about the openindiana-discuss
mailing list