[Dev] Problem root caused with review pending => Re: Critical vconf issue causing subtle failures throughout much of the tizen middleware

Rusty Lynch rusty.lynch at intel.com
Thu Oct 10 22:23:07 GMT 2013


The reason key creation fails at image creation time is because of some
broken logic in vconf attempting to handle the many race conditions that
existing using the old broken startup scripts where there was no good
way of ensuring a service was started after another dependent service.

In this specific case attempting to set a key
when /tmp/vconf-initialized does not exist would result an empty key
file created.  This tmp file is created by a vconf initialization script
that happens on every boot, but since that does not happen at image
creation files then all the packages that attempt to set keys in post
sections end up littering the vconf space with empty files.

A fix has been submitted to:
https://review.tizen.org/gerrit/#/c/10749/

On Thu, 2013-10-10 at 11:29 -0700, Rusty Lynch wrote:
> Looking at this just a little further, the i can clarify the second
> issue:
> Any attempt to set a vconf key from a post section of an rpm running at
> image creation time will result in an empty key.  Since packages are
> doing this with the "-i" option set to cause the key to be added to the
> memory backing store, then we end up with a memory backup store full of
> empty values
> 
> 
> On Thu, 2013-10-10 at 11:23 -0700, Peters, Brad T wrote:
> > The early vconf copy has long been painful, and we used to have a 
> > script which copied initial values out of a static directory filled
> > with 
> > initial values into a live image at startup.
> > 
> > 
> > Not sure if that script made the transition to a systemd service
> > 
> > 
> > What you're describing sounds like 2 bugs;
> >  1) a vconf bug where vconf is not properly handling an empty
> > key/value, and 
> >  2) an issue where initial values are not populating the vconf db. I
> > would recommend 
> >    targeting this issue at vconf, as well
> > 
> > 
> > Best,
> > -Brad
> > 
> > 
> > On Thu, Oct 10, 2013 at 11:07 AM, Rusty Lynch <rusty.lynch at intel.com>
> > wrote:
> >         While attempting to debug a bug with the audio session manager
> >         where any
> >         operation would take a crazy long time to finish, I found that
> >         the
> >         problem was that an in-memory vconf key was set with no data.
> >          Vconf
> >         would then do a series of retries to re-read data from the key
> >         when the
> >         key is in fact just empty, where each retry is 100ms.
> >         
> >         Without worrying about fixing vconf (since there is a team
> >         going off to
> >         create a replacement for that), I wanted to understand why my
> >         vconf key
> >         was set with no data in the first place.  On further
> >         investigation i
> >         could see that the memory keys are initially populated with a
> >         set of
> >         defaults from /opt/var/kdb/memory and that ALL of the defaults
> >         were just
> >         empty files.
> >         
> >         Looking into this a little further i can see that each of the
> >         entries
> >         in /opt/var/kdb/memory were populated via the post section of
> >         various
> >         packages where the post section would use the vconftool
> >         command to set
> >         the default value.  While this technique works when installing
> >         a package
> >         on a running live image, it fails when running at image
> >         creation time.
> >         
> >         I don't know why this fails at image creation time, but I see
> >         a lot of
> >         these empty default files and I suspect that each of these are
> >         triggering some subtle, hard to debug failure condition.  In
> >         the case of
> >         the audio-session-manager it makes the system appear to run
> >         very very
> >         very slow.
> >         
> >         Where should I file a bug for this?  This isn't IVI specific.
> >         Who would
> >         own fixing this... the mic developers or the vconf developers?
> >         
> >             --rusty
> >         
> >         _______________________________________________
> >         Dev mailing list
> >         Dev at lists.tizen.org
> >         https://lists.tizen.org/listinfo/dev
> > 
> > 
> > 
> > 
> > -- 
> > Best regards,
> > Brad Peters
> > Intel SW Engineer 
> >  and Tizen Mobile Lead
> 
> 
> _______________________________________________
> Dev mailing list
> Dev at lists.tizen.org
> https://lists.tizen.org/listinfo/dev




More information about the Dev mailing list