Login attention sound on continuous repeat after user switch

[fuzzyBSc]

This bug may be the same as bug 237429, but my triggering conditions are different. Like 237429, I get a continuous drumming noise. I am able to reproduce this on both of my Ubuntu machines (running 9.04). Steps to reproduce are:
1. Log in user 1 on a freshly-booted machine
2. Switch to user 2, supplying credentials
3. Switch back to user 1 and log out
4. Note that we have returned to the gdm prompt, but user 2 is still logged in.
5. Enter login and credentials for user 2
6. Note drumming on continuous repeat. The repeat interval is probably a little more than a second. The sound is the same as is used to call attention to the gdm login prompt being available.

Unlike 237429, this does not happen for me every time I switch users. Logging out stops the drumming, and the drumming does not restart on login. It appears to be a problem with the interaction between gdm and an already-logged-in session.

[Mark A. Nicolosi (mark-a-nicolosi)]

I'm having the same issue. Logging out and in seems to fix it, but it's a pain.

[Mark A. Nicolosi (mark-a-nicolosi)]

In syslog I get messages like this:

May 13 00:00:03 lothlorien gdm[10496]: WARNING: Couldn't authenticate user
May 13 00:00:34 lothlorien last message repeated 10 times

And lines like this in auth.log:

May 13 00:01:14 lothlorien gdm[10496]: pam_unix(gdm:auth): check pass; user unknown
May 13 00:01:14 lothlorien gdm[10496]: pam_unix(gdm:auth): authentication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost=

I think it's a pretty safe assumption that this issue is with GDM. I've managed a really nasty workaround, because I hate logging out, I disabled aplay until this gets resolved:

$ sudo chmod -x /usr/bin/aplay

[Sebastien Bacher (seb128)]

Thanks for the bug report. This particular bug has already been reported, but feel free to report any other bugs you find.

[fuzzyBSc (benjamincarlyle-soundadvice)]

I would like to track the progress of this bug. Would you mind marking it as a duplicate of the report that you are referring to?

[Sebastien Bacher (seb128)]

I don't have the number handy but I did read similar issues before

[fuzzyBSc (benjamincarlyle-soundadvice)]

Are your referring to bug 237429? As noted, my triggering conditions are different but I would be happy for these to be investigated together. 237429 seems to indicate this happens on a normal fast user switch, which is not my bug. Note that the information in this bug (373961) suggests that gdm is the culprit, while bug 237429 is currently allocated to pulseaudio and alsa-driver. I would suggest that either they are different bugs, or that 237429 may be incorrectly allocated.

Not to teach grandma to suck eggs, but invalid seems to be an incorrect end state for bug 373961 if it is a genuine duplicate.

[Sebastien Bacher (seb128)]

do you have a reliable way to trigger the issue?

[fuzzyBSc (benjamincarlyle-soundadvice)]

Yes, as noted in the bug report. The trigger is user 1 logging out
back to gdm while user 2 still has a session going. When user 2 logs
in through gdm back to their running session.

This has happened reliably for me, 100% of the time so far after a
small number of attempts. My auth.log corresponds to Mark's findings
as follows. Also, using Ctrl+Alt+F-keys to get back to the gdm prompt
stops the repeat. A message is briefly present indicating exactly what
the auth.log is reporting, ie that the username or password is
invalid. Perhaps this is a simple as an enter key being effectively
held down in the X session gdm is using?

auth.log output from around the time the login attention sound starts:
May 16 14:16:23 lillian dbus-daemon: Rejected send message, 1 matched
rules; type="method_call", sender=":1.105" (uid=1002 pid=10668
comm="/usr/lib/indicator-applet/indicator-applet --oaf-a")
interface="org.freedesktop.DBus.Properties" member="Get" error
name="(unset)" requested_reply=0 destination=":1.124" (uid=0 pid=2961
comm="/usr/sbin/gdm "))
May 16 14:16:31 lillian dbus-daemon: Rejected send message, 1 matched
rules; type="method_call", sender=":1.105" (uid=1002 pid=10668
comm="/usr/lib/indicator-applet/indicator-applet --oaf-a")
interface="org.freedesktop.DBus.Properties" member="Get" error
name="(unset)" requested_reply=0 destination=":1.125" (uid=0 pid=2961
comm="/usr/sbin/gdm "))
May 16 14:16:32 lillian gdm[2961]: pam_unix(gdm:auth): check pass; user unknown
May 16 14:16:32 lillian gdm[2961]: pam_unix(gdm:auth): authentication
failure; logname= uid=0 euid=0 tty=:0 ruser= rhost=
May 16 14:16:34 lillian gdm[2961]: pam_unix(gdm:auth): check pass; user unknown
May 16 14:16:34 lillian gdm[2961]: pam_unix(gdm:auth): authentication
failure; logname= uid=0 euid=0 tty=:0 ruser= rhost=
May 16 14:16:36 lillian gdm[2961]: pam_unix(gdm:auth): check pass; user unknown
May 16 14:16:36 lillian gdm[2961]: pam_unix(gdm:auth): authentication
failure; logname= uid=0 euid=0 tty=:0 ruser= rhost=
May 16 14:16:38 lillian gdm[2961]: pam_unix(gdm:auth): check pass; user unknown
May 16 14:16:38 lillian gdm[2961]: pam_unix(gdm:auth): authentication
failure; logname= uid=0 euid=0 tty=:0 ruser= rhost=
May 16 14:16:40 lillian gdm[2961]: pam_unix(gdm:auth): check pass; user unknown
May 16 14:16:40 lillian gdm[2961]: pam_unix(gdm:auth): authentication
failure; logname= uid=0 euid=0 tty=:0 ruser= rhost=

2009/5/14 Sebastien Bacher <email address hidden>:
> do you have a reliable way to trigger the issue?
>
> --
> Login attention sound on continuous repeat after user switch
> https://bugs.launchpad.net/bugs/373961
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Sebastien Bacher (seb128)]

Not confirming the issue there and that's the first bug about a such issue report, that need to be handled by somebody who can trigger the bug easily

[fuzzyBSc (benjamincarlyle-soundadvice)]

Ok, may I suggest setting back to Unconfirmed status?

I am still able to reproduce this reliably. I experimented with pressing Tab instead of Enter at the gdm login prompt. Enter still puts the login cycle into continuous repeat. However Tab only plays the sound once as gdm returns to the login prompt behind the scenes as the console switches to the still-logged-in session. That seems like reasonable behaviour, so I'll have a quick look at the sources to see if anything obvious crops up regarding enter specifically.

[Sebastien Bacher (seb128)]

setting to new if you prefer bug since gdm change in years and you are the only one to get this issue apparently I doubt it will be worked by anybody there

[fuzzyBSc (benjamincarlyle-soundadvice)]

Ok, this is for my own benefit (and Mark's as he is having the same problem as noted above) as much as anyone's.

I put a strace on various gdm processes while this was going on. The strace shows read and writes consistent with the initial login as user 1, and the final login to switch back to user 2. Attached is the strace for at least one cycle after user 2's password is entered, which shows repeated reads of the characters \2, \n, repeatedly with the occasional \7 and L. The file descriptor to watch is 13, which I presume is from the active gdmchooser. The \2 and \n appear to be delimiters relating to the protocol between the processes (possibly one is a character count).

The strace on the gdm output doesn't appear too suspicious. I see something to do with VT switching soon after a QUERYLOGIN line for user 2 (shell):
write(8, "A:20,1\n"..., 7) = 7
kill(2997, SIGUSR2) = 0
sched_yield() = 0
poll([{fd=3, events=POLLIN|POLLPRI}, {fd=6, events=POLLIN|POLLPRI}, {fd=4, events=POLLIN|POLLPRI}], 3, -1) = 1 ([{fd=4, revents=POLLIN}])
read(4, "\nMIGRATE 2997 :20\n"..., 4095) = 18
open("/dev/console", O_WRONLY|O_NOCTTY) = 7
ioctl(7, VIDIOC_G_COMP or VT_ACTIVATE, 0x9) = 0
ioctl(7, VIDIOC_S_COMP or VT_WAITACTIVE, 0x9) = 0
close(7) = 0
write(8, "A\n"..., 2) = 2
kill(2997, SIGUSR2) = 0
sched_yield() = 0
poll([{fd=3, events=POLLIN|POLLPRI}, {fd=6, events=POLLIN|POLLPRI}, {fd=4, events=POLLIN|POLLPRI}], 3, -1

The reads into gdmchooser amount to:
read(0, "\2D\n"..., 1024) = 3
read(0, "\2lshell\n"..., 1024) = 8
read(0, "\2UPassword:\n"..., 1024) = 12
read(0, "\2lshell\n"..., 1024) = 8
read(0, "\2l\n"..., 1024) = 3
read(0, "\2r\n"..., 1024) = 3
read(0, "\2l\n"..., 1024) = 3
read(0, "\2DPlease enter your username\n"..., 1024) = 29
read(0, "\2NUsername:\n"..., 1024) = 12
read(0, "\2D\n"..., 1024) = 3
read(0, "\2l\n"..., 1024) = 3
read(0, "\2UPassword:\n"..., 1024) = 12
read(0, "\2Q\n"..., 1024) = 3
read(0, "\2e\nIncorrect username or password"..., 1024) = 79
read(0, "\2A\n"..., 1024) = 3
read(0, "\2l\n"..., 1024) = 3
(repeat)

The writes are:
write(1, "\2shell\n"..., 7) = 7
write(1, "\2\n"..., 2) = 2
write(1, "\2\n"..., 2) = 2
write(1, "\002xxxxxx\n"..., 8) = 8 <-nb password for shell erased.
write(1, "\2\n"..., 2) = 2
write(1, "\2\n"..., 2) = 2
write(1, "\2\n"..., 2) = 2
write(1, "\2\n"..., 2) = 2
write(1, "\2\n"..., 2) = 2
write(1, "\2\7L\n"..., 4) = 4
write(1, "\2\n"..., 2) = 2
write(1, "\2\n"..., 2) = 2
write(1, "\2\n"..., 2) = 2
write(1, "\2\n"..., 2) = 2
write(1, "\2\n"..., 2) = 2
(repeat)

Again this looks like a series of enter keys. I am increasingly of the opinion that a keyboard repeat is what is going on ...

[fuzzyBSc (benjamincarlyle-soundadvice)]

Ok. I have a workaround in code, and remain confident that the root cause is switching virtual terminals while a key is being pressed or has just been pressed causing a keyboard repeat.
I modified gdmopen.c and getvt.c. Wherever I saw the ioctl to switch virtual terminals (VT_ACTIVATE) I added a sleep(1) beforehand. My theory is that this places additional time between my enter key press and the virtual terminal switch, possibly allowing a keyup event to come through. The result for me is that this switches from a 100% occurrence to a 0% occurrence.
My conclusion is that either the ioctl handling or the x-server handling of keystrokes is wrong somewhere, which is further than I think I can take this myself. My workaround could be included trivially in gdm, but I don't think it is an optimal solution.
I would request that whoever this bug ends up with carefully walks through the steps to reproduce. If it can't be reproduced then we can perhaps compare notes as to which x-server is in use, etc. Perhaps it is something unique to my hardware configuration. However, I don't at this stage see any reason why this should be unique to my machine. I suspect any machine with a similar set of software running will experience this if the fast user switch is being used frequently.
Again, the steps to reproduce are:
1. Log in as user 1 on a freshly-booted machine
2. Fast user switch to user 2 without logging out
3. Fast user switch back to user 1 without logging out
4. Log out of user 1 only
5. Note that user 2 is still logged in, but we have returned to the gdm prompt. This is the starting condition for the bug, and always happens for me from this point regardless of how I got here.
6. Enter the login details of user 2, leading to a virtual terminal switch to the still-running user 2 session while gdm continues to run on its own virtual terminal
7. Observe the drumming sound as gdm repeatedly tries to log in with an empty user name and password string. The cycle is approximately 2s, the time that gdm pauses between user login retries

Available workarounds:
* Patch gdm as indicated, adding a sleep before any virtual terminal switch ioctls (ie VT_ACTIVATE)
* or Ctrl+Alt+F-whatever to get back to the virtual terminal that is stuck in a login cycle. This stops the repeating keystrokes and halts the login cycle until the next time you enter the login details of a user who already has a running session on a different virtual terminal.

Thanks.

[Sebastien Bacher (seb128)]

thank you for your work there, that seems a tricky issue indeed and not really a gdm one

[Joachim (joachimrs)]

i have the same issue.

/var/log/messages contains:

Jun 15 13:10:47 Obelix pulseaudio[15619]: pid.c: Stale PID file, overwriting.
[ Jun 15 13:11:17 Obelix kernel: [206051.810222] gvfsd-trash[15757]: segfault at 14 ip 080569f5 sp bf86e060 error 4 in gvfsd-trash[8048000+1e000] ]

this could be from user 2, which I logged out. IIRC the drum roll sound could be heared once already before login/ password back to user 1, so right after logout of user 2. (Trash has nothing to do with it I assume).

[Joachim (joachimrs)]

Just logged out to end the drum roll sound and realised that I too have the error message: wrong username and password on the then new login screen although I didn't enter anything yet, i.e. the error message is already there right after logout.

So it's here too the thing with empty username and password and gdm trying to log in.

[Sebastien Bacher (seb128)]

Could you try if that's an issue in karmic?

[fuzzyBSc (benjamincarlyle-soundadvice)]

The attention sound is not happening for me under the same conditions with Karmic. Actually, I don't seem to be getting any attention sound at all at the moment, but neither do I see any repeated messages in the auth log. It looks like it isn't a problem for me under Karmic.

[Sebastien Bacher (seb128)]

closing since that works in karmic