So i'm tempted to revert this (see below conversation about a system
update utility that's using plymouth). We could add a --mode argument
to show-message and complicate the plugins more, but probably easier to
just fix the caller in comment 0 to write to /dev/console instead?
is it common practice on BSD to rsync /etc/passwd around? Maybe bsd
could go back to using /etc/passwd?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/941673
Title:
performance of accounts-daemon is
Attachment 124799 pushed as c85b41d - user: check if user is in wheel more
efficiently
Attachment 124800 pushed as 98f4287 - daemon: get local users from /etc/shadow
not /etc/passwd
Attachment 124801 pushed as 14ca424 - daemon: don't call getspnam for local
users
Attachment 124802 pushed as
Created attachment 124802
daemon: constrain max local users to 50
Systems with tens of thousands of users don't want all those users
showing up in the user list.
Set a cap at an even 50, which should cover the lion's share of use
cases well. Of course, if a user not in the list explicitly
logs
Created attachment 124803
daemon: don't source user list from wtmp
wtmp can get rather large on some systems from ssh logins.
Furthermore it's pretty much completely redundant given the user
cache in /var/lib/AccountService
This commit changes the wtmp code to only get used for maintaining
login
i'm going to push these patches to master. They're loosely based on
ritz work in this bug, but they diverge in some significant ways:
1) i set a limit on the number of local users returned (ala comment 2)
2) i redid the wheel check to avoid needing an admin user cache
3) i cache shadow
Created attachment 124801
daemon: don't call getspnam for local users
We're already iterating over the whole shadow file, so
just cache the entries instead of calling getspname a
few lines later.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed
Created attachment 124799
user: check if user is in wheel more efficiently
We currently get all the groups a user belongs to in one pass,
then check each one to see if it's wheel.
It's much more efficient to just get the wheel group and check if
any of its members are the user.
--
You received
Created attachment 124800
daemon: get local users from /etc/shadow not /etc/passwd
For some sites, it's common practice to rsync around large
/etc/passwd files containing the password entries for remote
users. That means accountsservices' "assume /etc/passwd is local
users" heuristic falls over.
My understanding is this bug is obsolete. canonical contributed a more
general accountsservice feature for storing arbitrary metadata alongside
the user.
See bug 63733 for details.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
sounds like you know more about it than I do, but regardless, I don't
think there's anything left to accountsservice.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/844081
Title:
Unity Greeter -
okay, but that doesn't have anything to do with this bug. Canonical
already added the infrastructure to accountsservice, whether or not
lightdm uses the infrastructure is a different matter
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
Hi,
(In reply to Chris Bainbridge from comment #3)
main.c forks before opening the listening port (calls ply_create_daemon
before start_boot_server). Is this intentional?
Yes.
Would you consider it a bug in plymouthd?
No.
Upstart should wait until the parent exits. We exit the parent when
So this bug report doesn't seem right to me. The code doesn't call
ply_detach_daemon (which exits the parent) until after
ply_boot_server_listen. Are you sure you've pegged the problem right?
If so, can you explain the race to me in more detail?
--
You received this bug notification because you
I like this patch. Two requests, if you don't mind:
1) Can you make it in git-format-patch format so it has a commit message, etc ?
2) Can you do one preliminary clean up patch before this one that moves the
existing cases where the cache files are removed into a standalone function,
then
don't you need to clean up the icon too?
Aside from that, I wonder if we'll run into bug reports after this where
users lose their settings after a domain controller blip.
Maybe it should avoid cleaning up remote users?
--
You received this bug notification because you are a member of Ubuntu
Does the version of plymouth you're using have add_consoles_from_file()
in main.c ? If not, pulling in the commits that add that function and
then subsquently fix that function may fix this issue.
We used to infer serial consoles from the kernel command line. These
days we read them directly
Does the version of plymouth you're using have add_consoles_from_file()
in main.c ? If not, pulling in the commits that add that function and
then subsquently fix that function may fix this issue.
We used to infer serial consoles from the kernel command line. These
days we read them directly
I'm on the same page as Matthias, I think. I started to look into
merging this today, but I ran into a few issues that would be better
enumerated using bugzilla. If you could attach the individual patches
that would be great.
--
You received this bug notification because you are a member of
any chance you could update this again for git master?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/941673
Title:
performance of accounts-daemon is very poor
To manage notifications about this
any updates on this?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/941673
Title:
performance of accounts-daemon is very poor
To manage notifications about this bug go to:
There's a patch on a different bug, so duping this one to it.
*** This bug has been marked as a duplicate of bug 56729 ***
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/857651
Title:
Unable to
ritz, any chance you could get this applying against master (preferably
as a git-format-patch formatted patch) ?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/941673
Title:
performance of
Talked with Ritesh about this bug today on IRC. He's going to look into
using fgetgrent to create the hash table of local groups and use that.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/941673
See bug 40020 for other discussion about potentially creating a separate
config file.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/857651
Title:
Unable to hide users from login screen / user
Hi,
(In reply to comment #2)
I think I've worked out what is going on here (and which caused me to
raise the erroneous bug 42285):
great!
In ply_event_loop_process_pending_events(),
ply_event_loop_handle_timeouts() is being called *after* epoll_wait(),
but ply_event_loop_handle_timeouts()
Comment on attachment 60179
reference event sources before calling timeout handler to ensure events stay
valid for loop iteration.
Review of attachment 60179:
-
::: src/libply/ply-event-loop.c
@@ +1296,5 @@
+ {
+
Alright, pushed with minor changes:
http://cgit.freedesktop.org/plymouth/commit/?id=16c7b306b34839d95a05f246f2184a7aab03b180
Thanks for tracking this down!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
AccountsService sort of assumes users in /etc/passwd are local users
and that the 4 user network login cases are covered by nis/ldap/etc
I guess we should do some sort of sanity check and treat /etc/passwd
users as remote in the case the check fails. This way we sidestep all
the costly work
maybe we could just bail if there are greater than N found users. The
problem then is finding a suitable value of N.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/941673
Title:
performance of
30 matches
Mail list logo
