Bug#159606: general: Gnome packaging crash prone, Xsession.
Package: general
Version: N/A; reported 2002-09-04
Severity: important
-- System Information
Debian Release: 3.0
Architecture: i386
Kernel: Linux link 2.2.20 #1 Sat Apr 20 11:45:28 EST 2002 i586
Locale: LANG=C, LC_CTYPE=C
Hi,
I've found a few problems with the X startups: which often don't really
start X :)
I think many user problems would go away if permissions were checked when
gnome installs (or perms were tested in cron run). Since permission
checks are somewhat standard in other packages, this should be possible.
I find gnome is far to suceptible to not working. You log in with gdm
and then get kicked out - back to gdm. You finally get in (likely
by giving up your old desktop), you have no login environment. You
uninstall and reinstall - but required files are still missing. Load
gmc: sometimes it closes and opens in a loop.
When Gnome doesn't load it often leaves no log messages or console
messages as to why: you'd have to get the source or just guess.
I put an old script of mine below about the HOME directory and Gnome.
GDM BUG: GDM does not really login users correctly:
--> GDM logs in the user without a login ENVIRONMENT <--
--> XDM logs in the user WITH a POSIX login ENVIRONMENT <--
(xdm can launch gnome easily)
After much work figuring out why my login ENV wasn't being
loaded, I narrowed it down to GDM (because everything GNOME
works until GDM enters the picture). I wrote the author
and of course got no reply.
(You might not notice this unless you use a POSIX compliant
login environment that sets environment variable when. A
workaround for bash is below.)
DEBIAN BUG: Xsession
Xsession breaks the Xfree86 starup rules - with the meantion that
those 'old startups' didn't handle multiple startups. That is
is just plain wrong.
However, Xsession ISN'T IN THE LOOP for Gnome startup.
So, if its not 'IN THE LOOP' for starting the big few desktops, why
does it need to ignore Xfree86 configs which work with xinit, xdm,
startx (had Xsession not been there to misconfigure things ??)
That is: why does Xsession need to rename the startup files and
call them in a different order -- but add nothing new to the
startup process ??
Certainly, a 'run-parts' could be in the system 'xinit'. So
that is not an answer. Xinit, startx, xdm, ... have allways
been compatible with multiple window managers. That's nothing
new in any system.
However, Xsession breaks the POSIX starup rule that allows the
user to control their own starup in their home directory(s).
Of course the old configs *were* carefully organized to allow
system defaults AND user control as well - because it is the
unix way to allow the user to run non-root software they have
permission to run - they way they need to run it, right?
Thanks,
John D. Hendrickson
jdh@hend.net
johndhendrickson22124@yahoo.com
# --------------------------------------------------------------
#!/bin/sh
# Below: some talk and a script pertaining to Gnome files in $HOME,
# and some solutions to various broken things.
#
# NOT GAURANTEED, of course
#
# Q: Some users can log into Gnome - some can't.
# Q: I login with "gdm" - but it brings me back to the login.
#
# Gnome may not load or do WEIRD things if its file and directories are
# setup wrong. For example - after "gdm" loging you don't get a spash
# and it exits. Or no splash and just a plain destop. Also, you might
# find "gmc" is acting weird - like it will open and close immediately
# in a loop and applications aren't launching.
#
# The below script can fix some simple problems.
#
# Try this from the prompt to see if it will work.
# (insure X is shutdown first, of course)
#
# bash# X vt7 & xterm & # This should work. Ctrl-Alt-Backspace.
#
# If it does not - then you may have a STARTUP problem - not a Gnome
# configuration problem. Startup problems is a very big topic which
# can span X, /etc/profile, /etc/X11, pam, gdm.conf, ssh, Xsession,
# and worse. Try reinstalling :) As your linux distribution gets
# bigger - so trouble shooting problems.
#
# also try:
# bash# X vt7 & gnome-session &
#
# If that doesn't work but the first did - then you likely have a gnome
# configureation problem. However - if the second line worked - but
# your "gdm" logins don't. Hmm... Could be gdm - many something else.
#
# --->
# So don't bother with this script 1 and 2 worked as the same user in
# question.
# --->
#
# Gnome's greatest design flaw ist thoughtless startup complexity, poor
# error reporting, and no fail-safe, all combined. Why doesn't it just
# start a basic desktop and THEN go goofing around ?? :)
#
# Corrupt or misconfigured things like those little startbar apps,
# and incorrect launchers can cause severe enough problems to prevent
# you from getting in. SSH will cause problems too. Can't fix that
# here. The answer to those things are: start with a fresh user account and
# let gnome re-create the default structure. Step by step, get back
# what you can.
#
# Personally, that is why I like Motif - its seldom "surprising", seldom
# not functional. KDE? Nice. But its not all open source and it crashes too
# much. But definitely nice.
#
# My not gaurunteed advice is this. [Backing up your files first.]
# If some users can log in and other's can, its likely the startup files
# Gnome undocumentedly requires when loading.
#
#!/bin/sh
if [ "`id -u`" = "0" ] ; then
# if root user
if [ -z $1 ] || [ -z $2 ] ; then
echo "Root must provide args: user homedir" >> /dev/stderr
echo "Where homedir is fullpath of all users." >> /dev/stderr
exit
fi
USER="$1"
HOME="$2"
if [ ! -d "$HOME/$USER" ] ; then
echo "Users directory unknown." >> /dev/stderr
echo "Please adjust script." >> /dev/stderr
exit
fi
fi
echo "--> $HOME/$USER" >> /dev/stderr
cd $HOME/$USER
ALL=".gnome .gnome-desktop .gnome_private Desktop"
ALL="$ALL "".sawfish .sawmill .mc"
for x in $ALL
do
for y in $(find $x -type d) ; do chmod +xr $y ; done
chown -R $USER:$USER $x
chmod -R +r $x
done
# if you don't fix Trash, gmc will open and close continually... neat...
chmod 0700 .gnome/metadata.db .gnome-desktop/Trash.gmc
# X's authority mechanism do report errors correctly. But here we go.
chown $USER:$USER .Xauthority .ICEauthority
chmod 0600 .Xauthority .ICEauthority
mkdir gnome-old
rm .gnome/.gnome-smproxy*
# you might remove .gnome/metadata.db - if it is corrupt
rm -r /tmp/orbit-$USER
rm -r /tmp/sawfish-$USER
# NOTE: Destop is *has*to*be a link. But just incase it isn't...
mv Desktop gnome-old
ln -s $HOME/$USER/.gnome-desktop Desktop
# try uncommenting the below if the above didn't work
function func () {
mkdir gnome-old
mv .gnome gnome-old
mv .gnome-desktop gnome-old
mv .gnome-private gnome-old
mv Desktop gnome-old
#rm -r .gconf*
}
# func # uncomment if the permissions didn't work
# Now login with gdm as usual
# Note $USER may not have the authority to change permissions on some
# of the files. The answer is to run that script as root.
# Delete the chmod binary and never use it again :^)
# bash# export XUSERSEARCHPATH="$HOME:$PATH"
# This needs to be somewhere in your startup BEFORE X is executed.
# Use this if you find that when you click on things in the start panel
# they never open.
# A 'pet peive' of mine is that when you "log in" you are not actually
# logged in by POSIX standars. That is: when you login from GDM you
# get an "interactive NON LOGIN" ENVIRONMENT. The "environment" is the
# restrictions under which all programs run -- so environment is
# certainly critical as to unix.
# An indication this is happening is that you see: 'bash$ ' as a prompt
# instead of your 'user@hostname:/' prompt. Though ultimately the
# problem is worse.
# SO... to get "logged in" under a default Gnome distribution you must
# a) (fix the problem?) or b) specifically invoke bash with --login from an
# xterm
# Soo... HowDoI fixit? There are two ways - neither are POSIX.
# They aren't solutions: they are hacks for broken systems.
#
# 1) set BOTH ENV and BASH_ENV (see bash's manpage).
# 2) ln -s $HOME/.profile $HOME/.bashrc
# 3) if your using sh - forget it - your stuck with --login
#
Reply to: