After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 488960 - gnome-terminal on Solaris 10 does not clean up utmpx on exit (intermittent)
gnome-terminal on Solaris 10 does not clean up utmpx on exit (intermittent)
Status: RESOLVED FIXED
Product: vte
Classification: Core
Component: general
0.16.x
Other Solaris
: Normal normal
: ---
Assigned To: VTE Maintainers
VTE Maintainers
Depends on:
Blocks:
 
 
Reported: 2007-10-22 11:29 UTC by Rajan Singh
Modified: 2008-11-26 16:35 UTC
See Also:
GNOME target: ---
GNOME version: 2.19/2.20


Attachments
Patch for the bug (2.88 KB, patch)
2007-10-22 13:33 UTC, Rajan Singh
none Details | Review
Alternate patch (1.90 KB, patch)
2008-08-05 10:41 UTC, Behdad Esfahbod
committed Details | Review

Description Rajan Singh 2007-10-22 11:29:34 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.
Comment 1 Rajan Singh 2007-10-22 13:33:18 UTC
Created attachment 97629 [details] [review]
Patch for the bug
Comment 2 Rajan Singh 2007-10-31 07:03:24 UTC
Could someone please review the patch.
Comment 3 Rajan Singh 2007-11-28 13:36:43 UTC
Can someone have a look at this patch ?
Comment 4 Rajan Singh 2007-12-18 13:22:00 UTC
Behdad,

Could you please have a look at this patch ?
Comment 5 Behdad Esfahbod 2007-12-18 21:57:21 UTC
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.
Comment 6 Rajan Singh 2008-01-08 08:33:37 UTC
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.
Comment 7 Rajan Singh 2008-02-18 06:37:52 UTC
Behdad, could you please look into this.
Comment 8 Behdad Esfahbod 2008-02-18 07:03:13 UTC
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.
Comment 9 Rajan Singh 2008-03-13 11:48:32 UTC
Behdad,
Could you have a look at the patch.
Comment 10 Rajan Singh 2008-03-31 12:31:47 UTC
Behdad:ping :)
Comment 11 Brian Cameron 2008-04-07 19:57:27 UTC
Behdad, *ping*
Comment 12 Behdad Esfahbod 2008-08-05 10:41:01 UTC
Created attachment 115885 [details] [review]
Alternate patch

I'm more comfortable with the attached patch.  Can you please test it?
Comment 13 Rajan Singh 2008-08-13 10:26:29 UTC
Have verified the patch. Works fine.
Comment 14 Behdad Esfahbod 2008-08-13 16:09:21 UTC
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?
Comment 15 Christian Persch 2008-09-29 19:03:24 UTC
Yeah, I think it's safe.
Comment 16 Christian Persch 2008-11-07 11:12:46 UTC
(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
  • #0 __kernel_vsyscall
  • #1 read
    from /lib/tls/i686/cmov/libpthread.so.0
  • #2 n_read
    at pty.c line 769
  • #3 _vte_pty_close
    at pty.c line 1122
  • #4 vte_terminal_catch_child_exited
    at vte.c line 3181
  • #5 _vte_marshal_VOID__INT_INT
    at marshal.c line 143
  • #6 g_closure_invoke
    at gclosure.c line 767
  • #7 signal_emit_unlocked_R
    at gsignal.c line 3244
  • #8 g_signal_emit_valist
    at gsignal.c line 2977
  • #9 g_signal_emit_by_name
    at gsignal.c line 3071
  • #10 vte_reaper_child_watch_cb
    at reaper.c line 98


That's extremely inconvenient for developing g-t and vte :)
Comment 17 Behdad Esfahbod 2008-11-07 16:56:08 UTC
Maybe we can add a 50ms timeout for the read?
Comment 18 Christian Persch 2008-11-26 14:46:56 UTC
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.
Comment 19 Behdad Esfahbod 2008-11-26 15:03:55 UTC
Ok, lets commit and have people shout if it does bad.
Comment 20 Christian Persch 2008-11-26 15:26:53 UTC
Committed to trunk.
Comment 21 Behdad Esfahbod 2008-11-26 15:45:57 UTC
Did you intend to close?
Comment 22 Christian Persch 2008-11-26 16:35:28 UTC
Yes :)