Ticket #146 (closed defect: worksforme)
unauthenticated 'logout' fails to log out user
Reported by: | kaduk | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | Fall 2009 Release |
Component: | login chroot | Keywords: | |
Cc: | Fixed in version: | ||
Upstream bug: |
Description
If I 'kdestroy;unlog' before running logout from a terminal window, the 'logout' command appears to not actually do anything.
jdreed says he has seen this behavior as well, but it may be intermittent, or dependent on something non-obvious.
Change History
comment:2 Changed 16 years ago by jdreed
- Component set to login chroot
- Milestone set to Fall Release
comment:3 Changed 16 years ago by geofft
I could not reproduce this with just "kdestroy", "unlog", and "logout". However, I could quite certainly reproduce it with "kdestroy", "unlog", "fs flushv .", and then logout. (I didn't try reproducing this more than once.)
The AFS cache manager doesn't check permissions on, for instance, stat information; if I stat a file that the world can't stat and then unlog, I can still stat the file until the record is flushed from cache. I can come up with a couple of theories as to how this might be relevant.
comment:4 Changed 15 years ago by kaduk
I am doing a poor job reproducing this.
(It used to be very easy for me to do so.)
Also, the gnome-session-save manpage claims that the --kill
and --silent options that we use are deprecated
A manual gnome-session-save --force-logout seems to work okay in my limited testing.
There were two things that I tried that came close to reproducing -- having a presentation open in openoffice caused the logout to block, and popped up a dialog box or two to that effect, prompting me whether I wanted to save my work, etc..
Having a firefox window open before kdestroy; unlog; fs flushv; logout caused the logout to take a sizeable amount of time (maybe O(2 minutes)), but it did eventually succeed.
If no one else can reproduce (was anyone else ever able to reproduce?), I think we can close this.
Did you have any applications running besides the terminal? If you had something else running, it could have been trying to save state into your homedir somewhere.
I wasn't able to reproduce with just a terminal.