[16950] in Athena Bugs
sun4 8.3.10: xss
daemon@ATHENA.MIT.EDU (Camilla R Fox)
Wed Jul 7 15:18:59 1999
Message-Id: <199907071918.PAA26180@sweet-transvestite.mit.edu>
To: bugs@MIT.EDU
Date: Wed, 07 Jul 1999 15:18:51 -0400
From: Camilla R Fox <cfox@MIT.EDU>
System name: sweet-transvestite.mit.edu
Type and version: Ultra-5_10 8.3.10 (with mkserv)
Display type: ffb
Shell: /bin/athena/tcsh
Window manager: vtwm.gamma
(actually several machines, all running 8.3.10)
What were you trying to do?
run xss from my .startup.X with:
/usr/athena/bin/xss -no-splash -silent &
What's wrong:
the -silent option doesn't work as it should, but not
consistently. on sweet-transvestite, the following is
printed to the console:
08:58 xss: couldn't get password of "cfox"
08:58 xss disabling server builtin screensaver.
08:58 xss: you can re-enable it with "xset s on".
on several other machines (including the test cluster indy, and
ultra10, as well as mkc, and beeblebrox) the message is
simply:
09:00 xss disabling server builtin screensaver.
09:00 xss: you can re-enable it with "xset s on".
on smoke-screen (an SGI O2) there hasn't been such a message
printed the last few times I've tried, although I think I've
noticed it in the past. I don't get such a message on oliver,
(another O2), either, though.
On sweet-transvestite, there are other problems with xss
(reported, unfixed), so it's probably reasonable to not worry
about the spurious password message until xss doesn't crash the
X server).
What should have happened:
The -silent flag should keep xss from writing informational
messages to the console. It should also behave the same way
across platforms.
There is a password set in my .xscreensaver,
so xss should never fail to find a password for me.
Please describe any relevant documentation references:
The man page doesn't say how silent the -silent option should
be. If it isn't completely silent, this should be documented.
Also note that on O2's, there's an interaction between xss and
the monitor power saving. The monitor will (most of the time)
switch off after 10 minutes of inactivity - I've reported this,
but I don't know why it happens.
