[Dev] Critical vconf issue causing subtle failures throughout much of the tizen middleware
rusty.lynch at intel.com
Thu Oct 10 18:29:56 GMT 2013
Looking at this just a little further, the i can clarify the second
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
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
> 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
> On Thu, Oct 10, 2013 at 11:07 AM, Rusty Lynch <rusty.lynch at intel.com>
> 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
> problem was that an in-memory vconf key was set with no data.
> 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
> in /opt/var/kdb/memory were populated via the post section of
> 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?
> Dev mailing list
> Dev at lists.tizen.org
> Best regards,
> Brad Peters
> Intel SW Engineer
> and Tizen Mobile Lead
More information about the Dev