Re: [OpenIndiana-discuss] SOLVED: MATE 1.20 and updated GTK+3 for hipster
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
Re: [OpenIndiana-discuss] SOLVED: MATE 1.20 and updated GTK+3 for hipster
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
* SizeSize of I/O in bytes
* Offset Offset of I/O in kilobytes
* PathPath to file on disk
*
* EVENTS:
* sc-read System call read
* sc-writeSystem call write
* fop_readLogical 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
Re: [OpenIndiana-discuss] SOLVED: MATE 1.20 and updated GTK+3 for hipster
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.
--
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.zece...@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!
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] SOLVED: MATE 1.20 and updated GTK+3 for hipster
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ć
--
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.zece...@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!
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] SOLVED: MATE 1.20 and updated GTK+3 for hipster
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 ? -- 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 ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] SOLVED: MATE 1.20 and updated GTK+3 for hipster
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 ... I do not have load problems anymore, only curious... With best regards. -- 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.zece...@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! ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] SOLVED: MATE 1.20 and updated GTK+3 for hipster
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. -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/alanc ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] SOLVED: MATE 1.20 and updated GTK+3 for hipster
On Tue, Oct 23, 2018 at 4:38 PM Predrag Zečević - Technical Support Analyst wrote: > On 10/23/18 16:18, Aurélien Larcher wrote: > >> ... > >> Hints were OK ... Maybe package pkg:/system/library/fontconfig should > >> check for permissions (at least on upgrade - no idea - so people do not > >> waste time on such mistakes). > >> > > > > Maybe we should list pkg verify as one of the step to perform when > > reporting an issue. > > This would uncover system-specific peculiarities. > > > > Would be nice to have such checklist in oi-docs. > > > > Good that you found the origin of the issue, I was afraid that I broke > your > > system ;) > > > > Hi Aurélien, > > pkg verify would be easy IF you know where problems starts... > Indeed... does "global" pkg verify still spit a lot of noise? > For example I have missed to interpret some lines from truss output, but > with little help, all went fine - then I was able to check everything. > > 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?) > > Anyway, I am glad that I could share some new experience with OI. > Thank you! > > With best regards. > Predrag Zečević > >> ___ > >> openindiana-discuss mailing list > >> openindiana-discuss@openindiana.org > >> https://openindiana.org/mailman/listinfo/openindiana-discuss > > -- > 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.zece...@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! > > ___ > openindiana-discuss mailing list > openindiana-discuss@openindiana.org > https://openindiana.org/mailman/listinfo/openindiana-discuss > -- --- Praise the Caffeine embeddings ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] SOLVED: MATE 1.20 and updated GTK+3 for hipster
On 10/23/18 16:18, Aurélien Larcher wrote: >> ... >> Hints were OK ... Maybe package pkg:/system/library/fontconfig should >> check for permissions (at least on upgrade - no idea - so people do not >> waste time on such mistakes). >> > > Maybe we should list pkg verify as one of the step to perform when > reporting an issue. > This would uncover system-specific peculiarities. > > Would be nice to have such checklist in oi-docs. > > Good that you found the origin of the issue, I was afraid that I broke your > system ;) > Hi Aurélien, pkg verify would be easy IF you know where problems starts... For example I have missed to interpret some lines from truss output, but with little help, all went fine - then I was able to check everything. 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?) Anyway, I am glad that I could share some new experience with OI. With best regards. Predrag Zečević >> ___ >> openindiana-discuss mailing list >> openindiana-discuss@openindiana.org >> https://openindiana.org/mailman/listinfo/openindiana-discuss -- 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.zece...@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! ___ openindiana-discuss mailing list openindiana-discuss@openindiana.org https://openindiana.org/mailman/listinfo/openindiana-discuss
Re: [OpenIndiana-discuss] SOLVED: MATE 1.20 and updated GTK+3 for hipster
On Tue, Oct 23, 2018 at 4:13 PM Predrag Zečević - Technical Support Analyst wrote: > On 10/23/18 15:58, Udo Grabowski (IMK) wrote: > > On 23/10/2018 15:44, Predrag Zečević - Technical Support Analyst wrote: > >> On 10/23/18 15:02, Udo Grabowski (IMK) wrote: > >>> On 18/10/2018 16:59, Alan Coopersmith wrote: > On 10/18/18 05:55 AM, Udo Grabowski (IMK) wrote: > > This is strange, why in the world should the settings-daemon > > read the fontpathes in an infinite loop ? Looks like its constantly > > thinking the mate font configuration has changed. > > I don't know about infinite loop, but you'll see libfontconfig > iterating > through all the fonts in all the directories when it thinks its font > caches are out of date. On Solarish systems, we have an SMF service > svc:/application/font/fc-cache to ensure the caches are up-to-date at > system boot and when IPS packages with fonts are installed, so it > would > be good to check that's running and not reporting any errors in the > SMF > logs for it. > > >>> > >>> For what I see from the 2483 time-sliderd truss output, it does the > >>> following for each /etc/X11/fontpath.d/*/ directory: > >>> > >>> Could it be that the change of the modification time (2) from 2483 > >>> triggers the reread by 2484 (mate-settings-daemon) ? > >>> ... > >> ... > >> > >> So, font cache fails to "recognize" fonts, and just keeps system busy > >> with creating cache, over and over. > >> ... > >> How to solve that situation? > >> > > > > Just to check that theory: Could you run the problematic BE and > > switch off the time-sliderd ? After settling down, the caches > > shouldn't be refreshed anymore if that assumption is correct. > > > > Otherwise, maybe the frequency of directory checking is just too > > high, given the vast amount of directories to check, which takes > > a considerable amount of time ? > > Hi again! > > First, I want to say big "thank you" to Dr. Udo Grabowski and Michal Nowak! > > Problem was related to directory permission and fonts cache: > > $ ls -hlad /beadm/var/cache/fontconfig/ /var/cache/fontconfig/ > drwxr-xr-x 2 predrag_zecevic admin 119K Oct 23 13:36 > /beadm/var/cache/fontconfig/ > drwxr-xr-x 2 predrag_zecevic admin 410 Oct 23 13:39 /var/cache/fontconfig/ > > $ pkg search /var/cache/fontconfig > INDEX ACTION VALUEPACKAGE > path dirvar/cache/fontconfig > pkg:/system/library/fontconfig@2.13.1-2018.0.0.1 > > $ pkg fix pkg:/system/library/fontconfig >Packages to fix: 1 >Create boot environment: No > Create backup boot environment: Yes > > Repairing: > pkg:// > openindiana.org/system/library/fontconfig@2.12.4,5.11-2018.0.0.0:20180211T124718Z > PACKAGE > STATUS > pkg://openindiana.org/system/library/fontconfig > ERROR > dir: var/cache/fontconfig > ERROR: Owner: 'predrag_zecevic (2903)' should be 'root (0)' > ERROR: Group: 'admin (1961)' should be 'bin (2)' > ... > > $ pkg -R /beadm fix pkg:/system/library/fontconfig > Packages to fix: 1 > > Repairing: > pkg:// > openindiana.org/system/library/fontconfig@2.13.1,5.11-2018.0.0.1:20181014T201419Z > PACKAGE > STATUS > pkg://openindiana.org/system/library/fontconfig > ERROR > dir: var/cache/fontconfig > ERROR: Owner: 'predrag_zecevic (2903)' should be 'root (0)' > ERROR: Group: 'admin (1961)' should be 'bin (2)' > ... > > > Do not ask me how my account had become owner of /var/cache/fontconfig > (and when)... > > After actions from above, I have deleted all files from > /beadm/var/cache/fontconfig, unmounted BE and booted into it. > > Everything went back to normal (I am writing this from BE oi_181018 now) > :-) > > Content of /var/cache/fontconfig changes (grows) when I start new > application, but that it is (as I have deleted all files before boot > into BE)... > > Hints were OK ... Maybe package pkg:/system/library/fontconfig should > check for permissions (at least on upgrade - no idea - so people do not > waste time on such mistakes). > Maybe we should list pkg verify as one of the step to perform when reporting an issue. This would uncover system-specific peculiarities. Would be nice to have such checklist in oi-docs. Good that you found the origin of the issue, I was afraid that I broke your system ;) > > One more time, big thanks to everybody... > > 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.zece...@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! > > ___ >
