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: Fri, 30 Jan 2009 22:56:15 -0600 (CST)

On Fri, 30 Jan 2009, Jeff wrote:

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

Hi Jeff,

I run Gentoo so I can't verify the problem here but I can tell you of the
strange way Gentoo starts LCDd: it uses the -f option to LCDd to tell it
to start in the foreground but the init script uses a function called
start-stop-daemon with the --background to force it into the background.

I looked at the init scripts packaged with lcdproc for Redhat and it uses
the daemon function. I don't know how it works or even if Fedora is using
that for the init script but bear with me...

I wonder if the method Gentoo uses somehow makes it possible for the
child's USR1 signal to actually reach the parent process? It shouldn't
matter if the parent is already detached when it forks the child but
looking at the code in server/main.c it seems like there has been some
problems with this on different platforms.

I'm running kernel version 2.6.25. Did starting LCDd ever work with a
kernel prior to 2.6.26?

Please post a copy of the init script Fedora 8 uses so we can see if the
distribution has changed it from what comes with lcdproc.

-Daryl




Archive powered by MHonArc 2.6.18.

Top of page