[OpenIndiana-discuss] SOLVED: MATE 1.20 and updated GTK+3 for hipster
Udo Grabowski (IMK)
udo.grabowski at kit.edu
Wed Oct 24 11:51:03 UTC 2018
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.
*/
}
--
Dr.Udo Grabowski Inst.f.Meteorology & Climate Research IMK-ASF-SAT
http://www.imk-asf.kit.edu/english/sat.php
KIT - Karlsruhe Institute of Technology http://www.kit.edu
Postfach 3640,76021 Karlsruhe,Germany T:(+49)721 608-26026 F:-926026
More information about the openindiana-discuss
mailing list