[4995] in testers
ssh -l root, console Sun logins, gnomecc top-levels
daemon@ATHENA.MIT.EDU (Mitchell E Berger)
Sun Jul 15 07:01:22 2001
Message-Id: <200107151101.HAA20924@byte-me.mit.edu>
To: testers@MIT.EDU
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Sun, 15 Jul 2001 07:01:18 -0400
From: Mitchell E Berger <mitchb@MIT.EDU>
3 separate bugs here...
ssh -l root
===========
I've recently noticed that sshing into a machine as root doesn't result in
anything being printed to the console. I don't actually think this is a
behavior change from 8.4, but I do think it's bad. Most people that care are
probably used to seeing something on the console if root logs in, and this
is indeed what happens if you either su, or do a Kerberized login as root.
Can we change this?
gnomecc top-levels
==================
I keep forgetting to report this... if you run the control center and click on
the top-level entry in the left pane for sawfish, you'll notice that the right
pane doesn't show anything for sawfish. Lower level sawfish categories show
up fine, but you can't make anything appear for the top level. Note that if
you run the sawfish configurator via its keybindings, it does indeed have a
top-level screen with configuration settings that you might well want to
change (if I remember correctly, for example, the user level must be changed
this way, and so you can't see advanced options unless you figure out to run
it that way). I believe the other capplets work in the same way, but I'm not
100% sure. Nothing promising stood out on Gnome's Bugzilla, but maybe someone
else would have better luck.
Console Sun logins
==================
I've known for a long time that often when you Ctrl-P xlogin on a Sun to do a
console login, it wouldn't print the message "Console login requested", and
after you type a username, you'd get a message from ttymon warning you that it
couldn't allocate a controlling tty for /dev/console. If you continue to log
in, you get a shell with no job control. I was fairly confident that this too
was a dm problem and we could fix it at the same time as the other Sun console
issue. I tried lots of changes to dm, and none of them helped. I then found
the pattern - it fails in this way when dm is respawned after a logout, but
not if dm has just started either for the first time or after a console login.
Trussing dm was very instructive... the results are in
~mitchb/Public/dm-truss-{beforelogin|aftergnomelogin}. In the gnome one,
things start to go wrong on line 65 where it tries to do an ioctl with
TIOCGSID. This corresponds to line 53 in the beforelogin version. The same
thing happens again later at line 546 in the gnome version versus line 536 in
the beforelogin version. The first ioctl corresponds to the tcsetpgrp call in
console_login() in dm.c. Of interesting note is shortly after the failed
ioctl, when dm begins to close all file descriptors >=3, none of them are
open, whereas in the beforelogin version, it successfully closes fds 3, 4, and
5. Something is closing files on us that shouldn't. I figured if it wasn't
dm, it must be xlogin, so I looked there, and it's not.
Finally, I noticed something important - it doesn't fail if you Ctrl-P after
logging out of a Dash-based session. The truss for this case is
dm-truss-afterdashlogin in the same directory. Other than the PIDs and time
values, it only differs from the beforelogin one on two lines. I logged
ljtest (a basically clean account) into a dash session, killed off Dash and
mwm, and simulated the gnome startup sequence (sawfish, capplets,
panel-wrapper, gnome-terminal, all as run from the default xsession). It
doesn't fail if you Ctrl-P after this. I tried commenting all those lines out
from xsession. It doesn't fail then either. Uncommenting the lines one by
one, I found that it will fail if you enable panel-wrapper, but only if it's
started through xsession and not afterwards (otherwise my simulated login
would have failed). I don't intend to debug inside panel and my guess is it's
not worth it to and we don't have time. However, it's a bug, it's annoying,
and now we have all the details someone that wants to investigate the problem
further should need.
Mitch
