LCDproc development and user support list

Text archives Help


[Lcdproc] LCDd daemon hangs with USB Crystalfontz 634 LCD


Chronological Thread 
  • From: wyatt at prairieturtle.ca (Daryl F)
  • Subject: [Lcdproc] LCDd daemon hangs with USB Crystalfontz 634 LCD
  • Date: Thu, 29 Jan 2009 14:08:59 -0600 (CST)

On Thu, 29 Jan 2009, Jeff Artz wrote:

> Does anybody have anything to suggest? It's now been a month since I
> posted my issue, but haven't even gotten a single response...
>
> :-(
>
> Jeff
> ----- Original Message -----
> From: Jeff Artz
> To: lcdproc
> Sent: Sunday, December 28, 2008 11:07 PM
> Subject: [Lcdproc] LCDd daemon hangs with USB Crystalfontz 634 LCD
>
>
> Ok, I've googled and found some references to this hang, and my new CF
> 634 display does the same, exactly as described in this thread from last
> year:
> http://lists.omnipotent.net/pipermail/lcdproc/2007-April/011646.html
>
> I'm running Fedora Core 8, kernel "2.6.26.6-49.fc8", current CVS LCDproc
> v0.5.2
>
> Here's what happens:
> [mythtv at mythbackend etc]$ sudo /sbin/service LCDd start
> Starting up LCDd:
> <hangs forever unless CTRL-C is pressed or a "kill -USR1" is issued...>
>
> ps ax of above hang scenerio:
> [root at mythbackend mythtv]# ps ax | grep LCDd
> 16361 pts/1 S+ 0:00 /bin/sh /sbin/service LCDd start
> 16368 pts/1 S+ 0:00 /bin/sh /etc/init.d/LCDd start
> 16373 pts/1 S+ 0:00 /bin/bash -c ulimit -S -c 0 >/dev/null 2>&1 ;
> /usr/local/sbin/LCDd -c /home/mythtv/lcd/LCDd.conf
> 16374 pts/1 S+ 0:00 /usr/local/sbin/LCDd -c
> /home/mythtv/lcd/LCDd.conf
> 16375 ? Ss 0:00 /usr/local/sbin/LCDd -c
> /home/mythtv/lcd/LCDd.conf
> 16381 pts/3 R+ 0:00 grep LCDd
> [root at mythbackend mythtv]#
>
> If I manually do a "kill -USR1 16374", "[ OK ]" is displayed and the
> prompt will come back and everything works fine.
>
> So, to help troubleshoot, I changed the ReportLevel to 5, and here's what
> I get to stdout:
> [mythtv at mythbackend etc]$ sudo /sbin/service LCDd start
> Starting up LCDd: LCDd version 0.5.2 starting
> Built on Dec 22 2008, protocol version 0.3, API version 0.5
> Using Configuration File: /home/mythtv/lcd/LCDd.conf
> Set report level to 5, output to stderr
> Server forking to background
> Listening for queries on 127.0.0.1:13666
> screenlist_init()
> driver_load(name="CFontz", filename="/home/mythtv/lcd/CFontz.so")
> CFontz: using Device /dev/lcd
> CFontz: init() done
> Key "Escape" is now reserved in exclusive mode by client [-1]
> Key "Enter" is now reserved in shared mode by client [-1]
> Key "Up" is now reserved in shared mode by client [-1]
> Key "Down" is now reserved in shared mode by client [-1]
> screenlist_process()
> screenlist_switch(s=[_server_screen])
> screenlist_switch: switched to screen [_server_screen]
> screenlist_process()
> screenlist_process()
> screenlist_process()
> screenlist_process()
> screenlist_process()
> screenlist_process()
> screenlist_process()
> screenlist_process()
> screenlist_process()
> screenlist_process()
> <etc... And then the running 'mythlcdserver' process starts displaying
> screens within a few seconds>
>
> (Which doesn't seem very helpful to me - perhaps it will to the
> developers)
>
> So for the moment I can't setup LCDd to start at boot time, or it will
> hang my system. I manually start it after booting. (Thankfully that's not
> very often, as it's my MythTV backend system)
>
> How can I help troubleshoot this further? (Suggestions of a debugger
> and/or the process, not quite step-by-step, but the more explict the better
> - ie please don't reply with simply "just debug the process"... I don't
> know how to do that [yet]!)
>
> Thanks!
>
>
> ------------------------------------------------------------------------------
>
>
>

Hi Jeff,

It may be that the child is sending the USR1 signal but it is being
blocked from the parent because of permissions. Instead of a `ps ax` try
`ps -ef` and see who owns the processes.

I suspect the init script is running as root and also the parent LCDd
process but the child is running as a less privileged user and the signal
is not being delivered. The assumption hear is that the `kill -USR1 <pid>'
is manually being done from a root login so it gets delivered and then the
parent ends and the init script completes and delivers the [ OK ] to the
console.

Post the `ps -ef'. Maybe someone else on this list can figure out what
needs to be done if it is permissions at fault.

-Daryl




Archive powered by MHonArc 2.6.18.

Top of page