LCDproc development and user support list

Text archives Help


[Lcdproc] LCDd daemon hangs with USB Crystalfontz 634 LCD


Chronological Thread 
  • From: bsdfan at nurfuerspam.de (Markus Dolze)
  • Subject: [Lcdproc] LCDd daemon hangs with USB Crystalfontz 634 LCD
  • Date: Sat, 31 Jan 2009 11:49:31 +0100

-------- Original-Nachricht --------
> Datum: Fri, 30 Jan 2009 18:51:29 -0500
> Von: Jeff <junk_inbox at verizon.net>
> An: lcdproc <lcdproc at lists.omnipotent.net>
> Betreff: Re: [Lcdproc] LCDd daemon hangs with USB Crystalfontz 634 LCD

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

the user privilege is changed after the signal has been sent, so this should
not be a problem.

Would you mind sending a log output of LCDd? You will have to rebuild LCDd
and use "configure --enable-debug". Then use ReportLevel=5 and
ReportToSyslog=yes in your LCDd.conf.

You probably want to add an entry to your syslog.conf as well:
!LCDd
*.* /var/log/LCDd.conf

(I am not sure if this works with Linux, but it should have something
similar.)

In the end you should see something like this:

<LCDd.log>
Jan 31 11:24:38 <user.notice> kirika LCDd: LCDd version 0.5dev starting
...
Jan 31 11:24:38 <user.info> kirika LCDd: Set report level to 5, output to
syslog
Jan 31 11:24:38 <user.info> kirika LCDd: Server forking to background
Jan 31 11:24:38 <user.debug> kirika LCDd: daemonize()
Jan 31 11:24:38 <user.info> kirika LCDd: parent = 1082
Jan 31 11:24:38 <user.info> kirika LCDd: child = 1083
Jan 31 11:24:38 <user.debug> kirika LCDd:
install_signal_handlers(allow_reload=1)
...
Jan 31 11:24:41 <user.debug> kirika LCDd: wave_to_parent(parent_pid=1082)
Jan 31 11:24:41 <user.info> kirika LCDd: child_ok_func(signal=30)
Jan 31 11:24:41 <user.debug> kirika LCDd: drop_privs(user="nobody")
Jan 31 11:24:41 <user.debug> kirika LCDd: do_mainloop()
</LCDd.log>

The lines wave_to_parent() and child_ok_func() should appear. After this you
should not see a process with the parent PID anymore!

Regards
Markus




Archive powered by MHonArc 2.6.18.

Top of page