desktop-packages team mailing list archive
-
desktop-packages team
-
Mailing list archive
-
Message #118661
[Bug 1443178] Re: Accounts Service always relies on language fallback if never set by the user
** Description changed:
+ trusty and vivid SRU requests
+ =============================
+
+ [Impact]
+
+ Until a user has set the language or regional formats explicitly,
+ accountsservice makes the system default values available. The code for
+ 'calculating' the system defaults is expensive, and it's triggered
+ frequently. The case in the original description of this bug report is
+ one example of bad performance for this reason. Another example is a
+ system with many users (see e.g. bug #1350393).
+
+ This upload adds a couple of static variables inside the function in
+ question, to avoid that the expensive code is executed at each
+ invocation. Under certain conditions this improves the performance
+ significantly.
+
+ [Test Case]
+
+ Hmm.. There is no easy use case to reproduce the bug. The original
+ description below gives a hint.
+
+ [Regression Potential]
+
+ On a multi-user system, if the system defaults in /etc/default/locale
+ are changed, accountsservice will keep providing the old system default
+ values until the system is rebooted. (Previously it took effect
+ instantly.) I think the advantages with the proposed change outweigh
+ this subtle change in behavior (which hardly anyone will notice anyway).
+
+ Can't think of anything besides that.
+
+ [Original description]
+
current build number: 169
device name: mako
channel: ubuntu-touch/devel-proposed
alias: ubuntu-touch/vivid-proposed
last update: 2015-04-12 20:38:14
version version: 169
version ubuntu: 20150412
version device: 20150210
version custom: 20150412
This causes a bad side effect when changing volume via indicator-sound,
as that will cause a sync to accountsservice in order to sync the
volume. Once that sync happens, it will request the user properties, and
in case the user doesn't have a valid language at
/var/lib/AccountsService/users/<user>, it will always rely on the
fallback, which would be fine if calculating the fallback wasn't 't so
cpu or i/o intensive (and that happens multiple times).
As a test, just flash latest vivid image on mako, don't set any language
when the wizard shows up, run top and then change the volume by pressing
volume up/down. This is what I see with mako:
- PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
+ PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2609 phablet 20 0 499660 121220 52688 S 7.6 6.5 0:41.69 unity8
5600 phablet 20 0 3676 1760 1288 R 6.0 0.1 0:00.19 language-option
1312 root 20 0 211532 15572 11344 S 1.9 0.8 0:07.25 unity-system-co
1316 phablet 20 0 36532 3792 2928 S 1.3 0.2 0:01.66 accounts-daemon
And the reason why:
src/user.c
...
static void
user_get_property (GObject *object,
- guint param_id,
- GValue *value,
- GParamSpec *pspec)
+ guint param_id,
+ GValue *value,
+ GParamSpec *pspec)
{
- User *user = USER (object);
+ User *user = USER (object);
...
- case PROP_LANGUAGE:
- if (user->language)
- g_value_set_string (value, user->language);
- else
- g_value_set_string (value, user_get_fallback_value (user, "Language"));
- break;
- case PROP_FORMATS_LOCALE:
- if (user->formats_locale)
- g_value_set_string (value, user->formats_locale);
- else
- g_value_set_string (value, user_get_fallback_value (user, "FormatsLocale"));
- break;
+ case PROP_LANGUAGE:
+ if (user->language)
+ g_value_set_string (value, user->language);
+ else
+ g_value_set_string (value, user_get_fallback_value (user, "Language"));
+ break;
+ case PROP_FORMATS_LOCALE:
+ if (user->formats_locale)
+ g_value_set_string (value, user->formats_locale);
+ else
+ g_value_set_string (value, user_get_fallback_value (user, "FormatsLocale"));
+ break;
user_set_property never gets called unless the user changes the system
language from system-settings or wizard.
Once you change the language, it will set a valid language at
/var/lib/AccountsService/users/<user>, causing this behavior to stop.
Another bad side effect of this issue is that it takes quite a while for
accountsservice to reply back to indicator-sound when the sync happens,
possibly causing sync aborts (as indicator-sound only waits 1 second
before triggering another sync).
Some possible ways to fix this issue:
1) Make wizard to set language even when the selected language is already the default one;
2) Change accountsservice to save the fallback value at the first time it gets that from the system;
** No longer affects: ubuntu-system-settings (Ubuntu)
** No longer affects: unity8 (Ubuntu)
** Also affects: accountsservice (Ubuntu Vivid)
Importance: Undecided
Status: New
** Also affects: accountsservice (Ubuntu Trusty)
Importance: Undecided
Status: New
** Changed in: accountsservice (Ubuntu Trusty)
Importance: Undecided => Medium
** Changed in: accountsservice (Ubuntu Trusty)
Status: New => In Progress
** Changed in: accountsservice (Ubuntu Trusty)
Assignee: (unassigned) => Gunnar Hjalmarsson (gunnarhj)
** Changed in: accountsservice (Ubuntu Vivid)
Importance: Undecided => Medium
** Changed in: accountsservice (Ubuntu Vivid)
Status: New => In Progress
** Changed in: accountsservice (Ubuntu Vivid)
Assignee: (unassigned) => Gunnar Hjalmarsson (gunnarhj)
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to accountsservice in Ubuntu.
https://bugs.launchpad.net/bugs/1443178
Title:
Accounts Service always relies on language fallback if never set by
the user
Status in the base for Ubuntu mobile products:
New
Status in accountsservice package in Ubuntu:
Fix Committed
Status in accountsservice source package in Trusty:
In Progress
Status in accountsservice source package in Vivid:
In Progress
Bug description:
trusty and vivid SRU requests
=============================
[Impact]
Until a user has set the language or regional formats explicitly,
accountsservice makes the system default values available. The code
for 'calculating' the system defaults is expensive, and it's triggered
frequently. The case in the original description of this bug report is
one example of bad performance for this reason. Another example is a
system with many users (see e.g. bug #1350393).
This upload adds a couple of static variables inside the function in
question, to avoid that the expensive code is executed at each
invocation. Under certain conditions this improves the performance
significantly.
[Test Case]
Hmm.. There is no easy use case to reproduce the bug. The original
description below gives a hint.
[Regression Potential]
On a multi-user system, if the system defaults in /etc/default/locale
are changed, accountsservice will keep providing the old system
default values until the system is rebooted. (Previously it took
effect instantly.) I think the advantages with the proposed change
outweigh this subtle change in behavior (which hardly anyone will
notice anyway).
Can't think of anything besides that.
[Original description]
current build number: 169
device name: mako
channel: ubuntu-touch/devel-proposed
alias: ubuntu-touch/vivid-proposed
last update: 2015-04-12 20:38:14
version version: 169
version ubuntu: 20150412
version device: 20150210
version custom: 20150412
This causes a bad side effect when changing volume via indicator-
sound, as that will cause a sync to accountsservice in order to sync
the volume. Once that sync happens, it will request the user
properties, and in case the user doesn't have a valid language at
/var/lib/AccountsService/users/<user>, it will always rely on the
fallback, which would be fine if calculating the fallback wasn't 't so
cpu or i/o intensive (and that happens multiple times).
As a test, just flash latest vivid image on mako, don't set any
language when the wizard shows up, run top and then change the volume
by pressing volume up/down. This is what I see with mako:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2609 phablet 20 0 499660 121220 52688 S 7.6 6.5 0:41.69 unity8
5600 phablet 20 0 3676 1760 1288 R 6.0 0.1 0:00.19 language-option
1312 root 20 0 211532 15572 11344 S 1.9 0.8 0:07.25 unity-system-co
1316 phablet 20 0 36532 3792 2928 S 1.3 0.2 0:01.66 accounts-daemon
And the reason why:
src/user.c
...
static void
user_get_property (GObject *object,
guint param_id,
GValue *value,
GParamSpec *pspec)
{
User *user = USER (object);
...
case PROP_LANGUAGE:
if (user->language)
g_value_set_string (value, user->language);
else
g_value_set_string (value, user_get_fallback_value (user, "Language"));
break;
case PROP_FORMATS_LOCALE:
if (user->formats_locale)
g_value_set_string (value, user->formats_locale);
else
g_value_set_string (value, user_get_fallback_value (user, "FormatsLocale"));
break;
user_set_property never gets called unless the user changes the system
language from system-settings or wizard.
Once you change the language, it will set a valid language at
/var/lib/AccountsService/users/<user>, causing this behavior to stop.
Another bad side effect of this issue is that it takes quite a while
for accountsservice to reply back to indicator-sound when the sync
happens, possibly causing sync aborts (as indicator-sound only waits 1
second before triggering another sync).
Some possible ways to fix this issue:
1) Make wizard to set language even when the selected language is already the default one;
2) Change accountsservice to save the fallback value at the first time it gets that from the system;
To manage notifications about this bug go to:
https://bugs.launchpad.net/canonical-devices-system-image/+bug/1443178/+subscriptions
References
