Custom Query (1145 matches)

Reported by jdreed, 15 years ago.

-> debathena / cluster-login-config / broder 15:39 (Evan Broder)

I can't actually spend time on it until this weekend, but the short story is that the cluster-login-config postinst (and postrm) should reload gdm and run for i in $(seq 1 6); do initctl (stop|start) tty$i

Reported by kaduk, 13 years ago.

In a stock install of cluster on natty, logins fail. This seems to be largely because when we run the session in the schroot, schroot's pam stack gets run, and it gives the user a new PAG (and keyring entry), but no tokens. Without tokens, access to the homedir fails, so the login bails pretty quickly.

Russ said that this may be because KRB5CCNAME is not in the PAM environment. However, the suggested possible workaround of adding always_aklog to the pam_afs_session arguments did not help. This may be because schroot is not fully running the session stack?

It will probably be useful to instrument a cluster login on lucid and see what has changed, so as to have a better sense of where to poke at to fix things.

Reported by broder, 13 years ago.

/etc/schroot/setup/15killprocs in schroot is responsible for making sure that no processes are still running in a chroot when that chroot is torn down.

It does this by looping over the processes still running in the chroot. For each process, it sends a SIGTERM, then immediately checks to see if the process is still running. If not, it then sleeps for 1 second before trying again.

The problem with this approach is that most programs try to handle SIGTERM gracefully, and therefore do not exit out immediately. When geofft instrumented the logout process, it looked like there were about 15 such processes, causing 15 seconds worth of sleep before the logout would continue.

This is the major cause of logout slowness on cluster machines.

When we used LVM snapshots for the login chroots, we had code to use fuser(1) to first SIGTERM and then eventually SIGKILL all processes running within the chroots, but we removed it from snapshot-run when we switched to aufs chroots.

Bringing that code back and adding it before snapshot-run calls schroot -e would eliminate this issue.