[Lcdproc] LCDd not loading properly

[Peter McCurdy]

On 4/24/07, brian <turbo@talstar.com> wrote:
> Peter McCurdy wrote:
> > It sounds like there's a problem in having the child process signal
> > the parent process that it's up and running.  When the original LCDd
> > process forks the child to run in the background, it sits in a wait(2)
> > system call for the child to either die (so the parent can exit
> > abnormally) or send signal SIGUSR1 saying that it started OK (so the
> > parent can exit normally).
> >
> > What happens if you 'kill -USR1' the parent LCDd process while it's stuck?
>
>    Okay, I just tried that.  Opened two ssh sessions into my MythTV box, and shut down the LCDd service.  In session one, I then ran
> "service LCDd start" and it 'hung' as usual.
>
>    In the second session, I first ran "ps ax | grep LCDd" and saw:
>
>      [root@myth ~]# ps ax | grep LCDd
>       8500 pts/2    S+     0:00 /bin/sh /sbin/service LCDd start
>       8503 pts/2    S+     0:00 /bin/sh /etc/init.d/LCDd start
>       8506 pts/2    S+     0:00 /bin/bash -c ulimit -S -c 0 >/dev/null 2>&1 ; /usr/local/sbin/LCDd -c /usr/local/etc/LCDd.conf
>       8507 pts/2    S+     0:00 /usr/local/sbin/LCDd -c /usr/local/etc/LCDd.conf
>       8508 ?        Ss     0:00 /usr/local/sbin/LCDd -c /usr/local/etc/LCDd.conf
>       8510 pts/3    R+     0:00 grep LCDd
>
>    So, then I typed "kill -USR1 8507" in the second session, and in the first session, saw:
>
>      [root@myth ~]# service LCDd start
>      Starting up LCDd:                                          [  OK  ]
>      [root@myth ~]#
>
>    ...in other words, *that* worked, and the service is running as expected:
>
>      [root@myth ~]# ps ax | grep LCDd
>       8508 ?        Ss     0:00 /usr/local/sbin/LCDd -c /usr/local/etc/LCDd.conf
>       8515 pts/3    R+     0:00 grep LCDd
>
>   So, now the question is:  Why isn't the child process sending the SIGUSR1 signal?

That's where I get lost.  Looking at the code, there doesn't seem to
be any plausible way for the child process to keep running (as it
does) but not send SIGUSR1.  I don't know many details about your
MythTV system; I gather it's based on Redhat, but what version?  Does
it do strange things with signals elsewhere?  Do you have a debugger
on there that can attach to the process when it starts?  If so, put a
breakpoint on the "wave_to_parent" function and see if it even tries
to send the signal.

It's particularly strange since this same code, including the init
script, works just fine for me on CentOS 4 and 5 (aka Red Hat
Enterprise Linux) without any fiddling.  So there's got to be
something odd with the system, either at build time or at runtime.

Peter.