LCDproc development and user support list

Text archives Help


[Lcdproc] LCDd daemon hangs with USB Crystalfontz 634 LCD


Chronological Thread 
  • From: junk_inbox at verizon.net (Jeff)
  • Subject: [Lcdproc] LCDd daemon hangs with USB Crystalfontz 634 LCD
  • Date: Fri, 30 Jan 2009 18:51:29 -0500

On Thu, Jan 29, 2009 at 3:08 PM, Daryl F <wyatt at prairieturtle.ca> wrote:

> 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
>
>

Thanks Daryl,

Here's the "ps -ef |grep LCDd" output while issuing a "/sbin/service start
LCDd" command:

[root at mythbackend ~]# ps -ef |grep LCDd
root 3667 3632 0 20:42 pts/5 00:00:00 /bin/sh /sbin/service LCDd
start
root 3675 3667 0 20:42 pts/5 00:00:00 /bin/sh /etc/init.d/LCDd
start
root 3680 3675 0 20:42 pts/5 00:00:00 /bin/bash -c ulimit -S -c 0
>/dev/null 2>&1 ; /usr/local/sbin/LCDd -c /home/mythtv/lcd/LCDd.conf
root 3681 3680 0 20:42 pts/5 00:00:00 /usr/local/sbin/LCDd -c
/home/mythtv/lcd/LCDd.conf
nobody 3682 3681 0 20:42 ? 00:00:00 /usr/local/sbin/LCDd -c
/home/mythtv/lcd/LCDd.conf
root 3686 23166 0 20:42 pts/1 00:00:00 grep LCDd
[root at mythbackend ~]#

(and you can see the parent running as root, and the daemon launced as
nobody)

If I comment out the "User=" line from the conf file, it still starts as
'nobody', and I get the same result.

If, however, I change it to "User=root", it starts as root and exhibits the
same behavior, so it doesn't appear to be a permissions issue:
[root at mythbackend ~]# ps -ef |grep LCDd
root 3800 3632 0 20:51 pts/5 00:00:00 /bin/sh /sbin/service LCDd
start
root 3807 3800 0 20:51 pts/5 00:00:00 /bin/sh /etc/init.d/LCDd
start
root 3812 3807 0 20:51 pts/5 00:00:00 /bin/bash -c ulimit -S -c 0
>/dev/null 2>&1 ; /usr/local/sbin/LCDd -c /home/mythtv/lcd/LCDd.conf
root 3813 3812 0 20:51 pts/5 00:00:00 /usr/local/sbin/LCDd -c
/home/mythtv/lcd/LCDd.conf
root 3814 3813 0 20:51 ? 00:00:00 /usr/local/sbin/LCDd -c
/home/mythtv/lcd/LCDd.conf
root 3816 23166 0 20:51 pts/1 00:00:00 grep LCDd
[root at mythbackend ~]#

PS: Same behavior with latest CVS - revision 1.29.2.4

Thanks,

Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.omnipotent.net/pipermail/lcdproc/attachments/20090130/2f5a6122/attachment-0001.htm>




Archive powered by MHonArc 2.6.18.

Top of page