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 <[email protected]> > 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 > [email protected] > https://lists.tizen.org/listinfo/dev > > > > > -- > Best regards, > Brad Peters > Intel SW Engineer > and Tizen Mobile Lead _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
