CK.OpenSession(): Do not block on run-seat.d scripts?
Hello William,
I am currently investigating boot speed improvements, and one particular item is that gdm hangs half a second in ConsoleKit.OpenSession(). The reason is that it synchronously calls all run-seat.d/* scripts, which includes udev-acl.ck.
I'm working on speeding up udev-acl.ck, but I need to discuss that with Kay Sievers first.
However, I wondered why it is synchronous in the first place: The hooks are called with a couple of environment variables, but CK does not read any kind of result from them. In other words, the scripts can't influence session properties, nor abort the creation of a session.
Is there a particular reason for CK to wait on all the hooks? If not, I'm happy to work on a patch to call those in the background. The only thing to watch out for, as far as I can see, is that a call to the hooks must not overlap with the next seat change, so this requires some locking.
Thank you, and Merry Christmas,
Martin
Signature · 2 lines
Martin Pitt | http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
On Mon, 21.12.09 15:17, Martin Pitt ([email protected]) wrote:
Heya,
Quoted 9 lines
I'm working on speeding up udev-acl.ck, but I need to discuss that with Kay Sievers first.
However, I wondered why it is synchronous in the first place: The hooks are called with a couple of environment variables, but CK does not read any kind of result from them. In other words, the scripts can't influence session properties, nor abort the creation of a session.
Quoted 5 lines
Is there a particular reason for CK to wait on all the hooks? If not, I'm happy to work on a patch to call those in the background. The only thing to watch out for, as far as I can see, is that a call to the hooks must not overlap with the next seat change, so this requires some locking.
We'd be very ill advised if (again) we'd do stuff like ACL fixes asynchronously in parallel to sending out the CK session messages. You really dont want that, because then clients which listen for session change messages could not rely on the ACLs being set up correctly when they get the message.
The dbus messages really need to be the last thing that happens, the seat.d hooks *must* be finished first, unless you are a sucker for raciness nightmares.
In HAL this used to be different (i.e. asynchronous), and among other reasons that's why HAL was broken.
Also note that /usr/lib/ConsoleKit/run-seat.d/udev-acl.ck is actually *not* a script. I cannot really believe that there is really that much to optimize here in this area... Except maybe that udev-acl might not be particularly fast since it iterates through the device list linearly?
Lennart
Signature · 3 lines
Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4