Help - Search - Members - Calendar
Full Version: Startxfce4 Script With Xdm
OESF Portables Forum > Archived Forums > Distros, Development, and Model Specific Forums > Zaurus Distro Support and Discussion > OpenBSD

I configured xdm for use with X-Deep32, and with no .xsession, it loads fvwm as expected and everything is ok. So I linked (ln) my .xinitrc to .xsession and expected to have a nice xfce4 loading in X-Deep32, but lo and behold, it doesn't start.

Here's the content of my .xsession :

export TERMCMD=aterm
exec /usr/local/bin/startxfce4 || exec xterm

and here's the content of the .xsession-errors :

/usr/local/bin/startxfce4: X server already running on display
Agent pid 121
/etc/xdg/xfce4/xinitrc[69]: dbus-launch:: not found
/etc/xdg/xfce4/xinitrc[84]: xfce4-session:: not found
Agent pid 121 killed

It seems there is already a X server running (which I think is normal with xdm) and I checked out the pid, it's a ssh-agent. I'm not quite sure why it's not starting right now, but I'm hoping one of you already had this problem. The startxfce4 script does work when I'm not running xdm. I googled my .xsession-errors and found out that I'm not alone, but I haven't found any answer.

The problem is probably the "xfce4-session:: not found" but "which xfce4-session" (/etc/xdg/xfce4/xinitrc[72]) correctly returns "/usr/local/bin/xfce4-session".

I'll look into it tonight, but any help is welcomed, as my experience with any *nix/bsd other than simple shell commands and vi is near zero. (Yes I'm using vi (gvim) on Windows... Notepad is for n00bs... lol)
run it from .xsession rather than .xinitrc don't load it from both... startxfce4 actually loads the X server when run from the console and I suspect it doesn't like being called twice... it is safest to call it from .xsession.

Pretty much ignore what you have in .xinitrc and concentrate on making .xsession a startup script for the session... mine looks something like this... (er exactly like this tongue.gif)

export TERMCMD=aterm
export LANG=en_GB
export PS1="\h$ "

Of course you may not be using aterm as the default terminal, may not be in the UK, may not need to tell PERL to shut up about locales it doesn't understand (en_GB) and may not want the prompt that I use.

in fact... take a look at the startxfce4 script and you will see that it attempts to call xinitrc just like the startx script would... take this as an indication that the script is a replacement for startx rather than xinitrc.

Well, did not have time yesterday, but here is what I have done.

1. Deleted .xinitrc and .xsession
2. Created new .xsession with :

export TERMCMD=aterm

3. Restarted xdm

Still has the same error.

Note that I use the full path in the .xsession because the PATH env isn't set because xdm doesn't parse my .profile, and calls no login shell. ( Anyone knows the "usual" location to set the PATH env when using xdm ? )

I'm still stuck. I'll look into it tonight, but again, any help is appreciated.
ok, it should work - however, there is a little 'telltale' in what you mentioned above..

You had to put /usr/local/bin/startxfce4 in the script because /usr/local/bin isn't in the path??

This kinda indicates that you are logging in as root... I haven't tried xfce4 from xdm as root.

All 'normal' users get /usr/local/bin in their path, its a sort of safeguard that root only has paths to default system stuff... avoid using root wherever possible, su when needed (your user must be in the wheel group to do this) or even better use sudo for admin type commands.

Give it a try with a regular user account. (that's if I'm right about what you are doing of course tongue.gif)

QUOTE(iamasmith @ Apr 13 2006, 01:35 PM)
This kinda indicates that you are logging in as root... I haven't tried xfce4 from xdm as root.

Of course, you were right. From a normal account it works flawlessly (well except the speed when I'm compiling abiword at the same time, but oh well... wink.gif)

Thank you.
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2018 Invision Power Services, Inc.