Can't log in graphically if quota is exceeded

[quentin]

I just observed a user who wasn't able to log in because he had exceeded his quota; he got as far as the zenity dialog telling him his quota was exceeded, and then the login session completely hung when he pressed the OK button in the dialog. The zenity window hung with the button depressed, and the login didn't continue. I had to walk him through sshing in from another machine to delete some files; that's not something that the average user is expected to be able to do.

[geofft]

This is exactly the same failure mode all my logins run into, because my home directory is chowned to geofft.root. PulseAudio? decides it can't create a lockfile in my homedir, and proceeds to hang, and apparently the Zenity dialog box wants to invoke PulseAudio? for some reason, too.

(I work around this by running an xterm in .startup.X, and killing the \PulseAudio? process by hand. At some point I'll just give up and get my homedir chowned back to geofft.)

Quentin on zephyr suggests running a systemwide PulseAudio? instance instead of one per user, by setting PULSEAUDIO_SYSTEM_START=1 in /etc/default/pulseaudio. That's probably reasonable, and may even marginally speed up logins.

[broder]

If we do want to make that change to the PulseAudio config, we also want to be sure to add users to the pulse-access group in reactivate.

[broder]

Hmm...so changing the PulseAudio? config is certainly one way to fix the issue, and would probably solve things for cluster logins, but wouldn't this still be a problem for workstation/login-graphical users?

Is there any way we can fix this for everybody, and not just cluster?

[broder]

Does PulseAudio? create its lockfile in the root of your homedir or in a subdirectory? Could we make a symlink into /tmp or something to satisfy it? You would obviously still lose if you were over quota the first time you logged into a Debathena machine, but it would be progress.

[broder]

Looks like the Ubuntu SRU team is currently looking into this issue, although for different reasons. If this patch gets backported to Jaunty, I think we'll be all set.

It'll mean that if you're over quota, you don't get sound, but if that's the worst your over-quota experience suffers, I'd say we're doing a damn good job.

[geofft]

Since this is "Critical", and since there's been no SRU activity... should we debathenify the package to add the patch, and depend on debathena-pulseaudio | pulseaudio (>= 0.9.14-0ubuntu20.3) in debathena-cluster?

[broder]

This finally got some attention from ubuntu-sru; it's in jaunty-proposed now and will hopefully move to jaunty-updates in a week or so.

[broder]

pulseaudio 1:0.9.14-0ubuntu20.3 hit jaunty-updates today. It's already hit the Media Lab mirror, so it should disseminate to the cluster machines within the next 6 hours or so.