On Mon, 2013-05-20 at 12:41 -0700, Adam Williamson wrote:
> > If we look at the permissions:
> >
> > [root@adam Beta-RC2]# ls -lZ /run/gdm/auth-for-adamw-szT11D/database
> > -rw-------. adamw adamw system_u:object_r:xdm_var_run_t:s0 /run/gdm/auth-for-adamw-szT11D/database
> > [root@adam Beta-RC2]# ls -dlZ /run/gdm/auth-for-adamw-szT11D/
> > drwx--x--x. adamw adamw system_u:object_r:xdm_var_run_t:s0 /run/gdm/auth-for-adamw-szT11D/
> >
> > note, the file is just 'database', while the strace shows 'database-c';
> > I don't know if that's significant.
>
> So ajax points out that the 'database-c' thing could be caused by "the
> '-c' from su's argv not getting a space before it". Sounds good, but
> you'd think that would happen *all the time*, and this bug doesn't
> happen all the time.
>
> One thing I neglected to note is where precisely the slowness occurs:
> what happens is that after each of those:
>
> nanosleep({2, 0}, 0x7fff8b56d5c0) = 0
>
> lines, the xauth process just sits there not doing anything for a second
> or two. So it tries seven times, sleeping for a couple of seconds after
> each failure, and that's the delay. So a possible theory is that the
> 'database-c' thing always happens, but for some other reason, xauth does
> not always sleep after a failure to read that non-existent file; in that
> case we have two issues to track down, first fix the erroneous -c thing,
> then find out why xauth decides to start sleeping after a failure. But
> we're still theorizing at present.
Eureka!
So ajax's theory was wrong. halfline was able to diagnose the issue
(nice job, halfline). It boils down to /run/gdm 's permissions being
wrong - they were 1770 on my system, they are supposed to be 0711. After
some head scratching, he also figured out when and why this happens: the
permissions are incorrectly specified in the spec file. gdm fixes them
on startup. So you see this bug when you get an update to the gdm
package without rebooting (or restarting gdm): the package install sets
the permissions to what is specified in the .spec file, and gdm doesn't
reset them because it's already running. That's why the bug isn't always
present, and goes away on a reboot.
Nice job halfline! He's going to fix the spec file to specify the
correct permissions.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
