Re: Hal and KDM breakage (was Re: KDE4 and input events stalled)

On Tue, 2009-04-07 at 11:59 -0700, David Wolfskill wrote:
> On Tue, Apr 07, 2009 at 02:40:08AM -0400, Joe Marcus Clarke wrote:
> > ...
> > The problem is due to the fact that console-kit-daemon will not work if
> > it starts up before init has started the ttys.  Therefore, hald needs to
> > come up after the getty processes have been spawned (i.e. after init has
> > started the ttys).
> 
> That would seem to contraindicate xdm (or similar) startup from
> /etc/ttys, in general.
> 
> > If the ttys were started as part of the rc.d process, this could be avoided.
> 
> Hmmm..
> 
> > This is why GNOME makes people use the rc.d script to start gdm.  It
> > just won't work out of /etc/ttys.
> 
> OK; I use xdm.  And following what I thought was appropriate, I fired it
> up out of /etc/ttys.
> 
> I did, however, want to tweak things a bit; in particular, since I
> regularly flip my laptop among stable/6, stable/7, and head, I wanted
> the login screen to provide a hint as to what the machine was running at
> the time.  So I cobbled up a shell script to copy Xresources to an
> appropriate place & apply sed(1) using selected output of uname(1).
> 
> That's worked for ... well, years.
> 
> But since hald(8) became involved in X, things got a bit ugly.
> 
> In particular, it seemed that xdm was getting started before hald, and
> that just wasn't helpful.  At least with the above explanation, I'm
> beginning to see why that is.
> 
> I tweaked dependencies to force xdm to come up after hald, but even so,
> that didn't help much: it seems that hald isn't really ready to provide
> the services asked of it immediately.

Note that it is dbus that needs to be active and working before
something tries to start X... X will wait on hald for a bit.

X will start up, register with dbus and ask for info from hald.  If hald
isn't up, or ready it will loop for a bit, waiting.  Once hald is up and
registers with dbus it will proceed.  At least that is my recollection
of how the code worked.

robert.

> So I hacked my xdm start-up script; it's got to the point where it seems
> to work pretty reliaably for me; maybe it will help someone else:
> 
> 
> #! /bin/sh
> 
> # PROVIDE: xdm
> # REQUIRE: hald dhclient moused ip_addr
> # KEYWORD: nostart
> 
> # This script is to be started from /etc/ttys, not /etc/rc.
> 
> . /etc/rc.subr
> 
> name="xdm"
> 
> case "$1" in
> start)
> 	if ! hald=$(check_process hald-addon-mouse-sysmouse); then
> 		sleep 5
> 		exit 1
> 	fi
> 	if [ ! -r /proc/${hald}/status ]; then
> 		sleep 5
> 		exit 1
> 	fi
> 	hald_start=`awk -F "[ ,]" '{print $8}' /proc/${hald}/status`
> 	now=`date "+%s"`
> 	# This was determined empirically
> 	hald_delay=8
> 	wait=$(($hald_start + $hald_delay - $now))
> 	if [ $wait -gt 0 ]; then
> 		info "$name start-up waiting $wait seconds for hald-addon-mouse-sysmouse"
> 		sleep $wait
> 	fi
> 	if [ -x /usr/local/bin/xdm ]; then
> 		old_dir=/usr/local/lib/X11/xdm
> 		new_dir=`/usr/bin/mktemp -d /tmp/.xdm-XXXXX`
> 		uname=`uname -v | sed -e "s/   .*$//"`
> 		sed -e "s/ Welcome to CLIENTHOST/ CLIENTHOST - ${uname}/" \
> 			-e "/greetFont/s/24-240/18-180/" \
> 			-e "s/Serif-24/Serif-18/" \
> 			${old_dir}/Xresources >${new_dir}/Xresources
> 		/usr/local/bin/xdm -nodaemon -resources "${new_dir}/Xresources"
> 	fi
> 	info "Starting ${name}."
> 	;;
> stop)
> 	[ -r /var/run/xdm.pid ] && \
> 		 kill `cat /var/run/xdm.pid` && \
> 		 rm -fr /tmp/.xdm-????? && \
> 		 info -n ' xdm'
> 	;;
> restart)
> 	$0 stop; $0 start
> 	;;
> *)
> 	err 1 "Usage: `basename $0` {start|stop}|restart"
> 	;;
> esac
> 
> exit 0
> 
> 
> [I originally tried merely sleeping a bit, but eventually found it more
> reliable to merely exit the script & let init(8) re-spawn it.)
> 
> Peace,
> david
-- 
Robert Noland <rnoland_at_FreeBSD.org>
FreeBSD