opie-login and qpe failure when -terminal NOT used, also note that prior Settings/qpe.conf values can lead to segfault

I spent some time over the weekend updating the a new OE build. I'm
having a harder time getting opie-login to work on my ipaq3835, than I
did a few weeks ago. Some things are better but some are worse.

If you get bogged down in the details below, try going to the simple
test at the end to see the problem without all the extra detail.

I was able to build a working opie login (1.1.5-cvs-20041001) patched in
the following way.
  1. Since "-terminal" is not a valid option I had to comment it out of
the /etc/init.d/opie script. In order to keep functionality I preceded
the opie-login call with a "terminal=1 ".
  2. I needed to use terminal=1 since that version of qpe couldn't read
the ipaq buttons from any other terminal. Because of this I needed to
disable the getty running on that port in /etc/inittab. The ability to
use terminal!=1 was recently fixed in the CVS tree.
  3. I took the older share/opie-login/ script from a Familiar
distribution and added support for my $terminal variable by doing a
"chvt ${terminal:-1}" in the pre-session script. I also added the
/dev/vc/0 and /dev/vc/${terminal:-1} to the list of devices to chown.
  4. The opie-session script needed to be changed so that it doesn't do
a -terminal option unless you're root, since it causes qpe to terminate.

Aside from the problem of respawning to fast, and not actually
daemonizing correctly, every thing worked great. I was able to run as a
normal user like I have been under Familiar for a year.

Now with the build from this weekend (1.1.5-cvs-20041025) some things
have changed, not all for the better.

  1. Still need to comment out -terminal but can now prepend terminal=2
to the opie-login in /etc/init.d/opie.
  2. Ipaq buttons now can be read on any terminal, you just need
permission.
  3. It would be nice if the chvt method still worked, but it doesn't
seem to be enough now. I can get the display up, and have all the
buttons work. But as soon as the system is powered down the screen
never comes back on.

Unless my opie-session file calls qpe with -terminal it seems to not be
able to power back on the display? This is not even a permission
problem since it occurs when logged in as root as well. I've modified
the opie-login to allow the -terminal option, but that doesn't seem to
make any difference since the running instance seems to come from
opie-session.

I would like to get a clean set of patches to submit but so far the only
solution seems to be to call qpe with -terminal and make certain that
your UID=0. I've set my UID to 0 in /etc/passwd and seem to be able to
run, but I wouldn't call it "running as a non-root user".

There is a simple test to see the problem I'm having without all the
opie-login complications:

/etc/init.d/opie stop
chvt 2
qpe -nodaemon
# your buttons should work fine.
# now push the power button and it turns off.
# now push the power button and it WILL turn on you just wont see it.

The system powers back on fine and qpe is still running but never turns
on the display again?

Any ideas where else to look?

One more thing that I did notice during all this that slowed me down. I
found that qpe was segfaulting without explanation. The solution was to
remove my old Settings/qpe.conf file. I don't know what the problem
was, if I get a chance I'll to a diff on it and put back in the changes
until I find the one that breaks everything.

I also can't really see why the daemon code respawns too quickly. I
quick look over it doesn't reveal anything obviously wrong. I guess
it's interesting that qpe and opie-login both fail to become a daemon in
the same way.

-- 
--------------------------------------------------------------
 Robert E. Anderson  		 	email: rea@sr.unh.edu
 Systems Programmer			phone: (603) 862-3489
 UNH Research Computing Center		  fax: (603) 862-1761
--------------------------------------------------------------