GNOME Bugzilla – Bug 488960
gnome-terminal on Solaris 10 does not clean up utmpx on exit (intermittent)
Last modified: 2008-11-26 16:35:28 UTC
Please describe the problem: When closing a gnome-terminal window, if it is not the last window to be closed, the utmpx file can be left with stale information in it. The "who" command will still report the user against the pts terminal. For example: # who root console May 25 16:46 test1 dtremote May 25 16:47 (beefy:0) test1 pts/3 May 25 16:53 (beefy:0.0) test1 pts/4 May 25 16:53 (beefy:0.0) (pts/3 and pts/4 represent two gnome-terminal windows, with a common pid) After the pts/4 window is closed # who root console May 25 16:46 test1 dtremote May 25 16:47 (beefy:0) test1 pts/3 May 25 16:53 (beefy:0.0) test1 pts/4 May 25 16:53 (beefy:0.0) The pts/4 entry still persists, but the terminal line is available for re-use. If a second user runs a gnome-terminal and is assigned pts/4 by the system, it fails to update the utmpx because of the existing record for the previous user, and thus operations which use the terminal line to work out the login name of the user (like password changing) do not work correctly. Steps to reproduce: 1. launch 2 instances of gnome-terminal (with user say test1) 2. Close one of these 3. Launch one more instance as different user (say test2) 4. Try to change the password $ passwd Actual results: User test2 will not be allowed to change the password. Will get an error message saying that it is trying to change password for user test1 and the operation is not permitted. Expected results: User test2 should be able to change its password. Does this happen every time? This happens intermittently. Other information: Will be putting up a patch.
Created attachment 97629 [details] [review] Patch for the bug
Could someone please review the patch.
Can someone have a look at this patch ?
Behdad, Could you please have a look at this patch ?
So, on Solaris the pty should be still open to be able to clean up its record? My other concern is, this is changing gnome-pty-helper's protocol. That can cause problems if people end up running a newer vte against an older gnome-pty-helper.
Yes, the pty needs to be open. This bug is seen only for a non-root user and the gnome-terminal should wait for utmp-update to clean up the database entry before closing the pty.
Behdad, could you please look into this.
Sorry, can't commit this right now because of freezes. Please ping again after GNOME 2.22 is out and I'll review and commit it.
Behdad, Could you have a look at the patch.
Behdad:ping :)
Behdad, *ping*
Created attachment 115885 [details] [review] Alternate patch I'm more comfortable with the attached patch. Can you please test it?
Have verified the patch. Works fine.
ChPe, do you think this is safe to go in? Can hang new vte is it ends up talking to old gnome-pty-helper. But we always spawn our own g-p-h, right?
Yeah, I think it's safe.
(In reply to comment #14) > ChPe, do you think this is safe to go in? Can hang new vte is it ends up > talking to old gnome-pty-helper. But we always spawn our own g-p-h, right? Actually this does lead to hangs. I had g-t 2.24 open with old vte, and running my g-t trunk (with --disable-factory) with vte trunk + this patch, and it hangs on closing a tab: (gdb) where
+ Trace 209388
That's extremely inconvenient for developing g-t and vte :)
Maybe we can add a 50ms timeout for the read?
Actually I cannot reproduce this anymore. I think I may just have made the error of not making install in gnome-pty-helper/ when trying this patch. So I'm ok with committing this now.
Ok, lets commit and have people shout if it does bad.
Committed to trunk.
Did you intend to close?
Yes :)