OK, sorry for the delay Roger. So if I understand correctly, the only
way to reproduce this problem is to create a new user when the users
list appears empty? That would be logical, since we commit the data we
have, which would be empty if it could not be loaded.
But do you mean that the second time you start users-admin, the users
list is empty even if you don't get the error message? That would be the
real failure here: we should never allow the tool to run if retrieving
data failed.
Then, another part of the issue is that the backends seem to be too slow
to start before the timeout is reached. That may come from the fact perl
needs quite a bit of memory to run, which may need some swapping. That's
relatively hard to solve, but at the very least we should display an
error, not destroy the system's configuration.
Xande: are you sure users-admin is starts faster after restoring the
backup? That seems really strange if the files are the same. One
interesting test (for both of you) would be to start the scripts before
starting users-admin, and to compare the startup times: start users-
admin once, run it again and see the time it needs, then wait for 5
minutes so that the scripts to stop automatically, and restart users-
admin to compare. The first time is needed so that the tool is loaded in
memory, but it should not be taken as reference for anything.
** Changed in: liboobs (Ubuntu)
Status: Confirmed => Triaged
--
Creating an user destroys most of users and groups configuration
https://bugs.launchpad.net/bugs/240437
You received this bug notification because you are a member of Ubuntu
Desktop Bugs, which is subscribed to liboobs in ubuntu.
--
desktop-bugs mailing list
desktop-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/desktop-bugs
