[Lcdproc] LCDd not loading properly

[Peter McCurdy]

On 4/24/07, brian <turbo@talstar.com> wrote:
> Stewart W. Putnam wrote:
> > I think that some sort of failure in the Foreground=no option is most
> > likely.
> >
> > Before wondering about anything more complex or mysterious, set
> > ReportLevel=5 in LCDd.conf and check a few things.  Run LCDd breifly,
> > long enough to display a few lines, then stop it.
> >
> > Look in syslog for a line like:
> > date:time localhost LCDd: Using Configuration File: /etc/LCDd.conf
>
>     Apr 24 10:30:43 myth LCDd: LCDd version CVS-current-20070317 starting
>     Apr 24 10:30:43 myth LCDd: Built on Mar 27 2007, protocol version 0.3, API version 0.5
>     Apr 24 10:30:43 myth LCDd: Using Configuration File: /usr/local/etc/LCDd.conf
>     Apr 24 10:30:43 myth LCDd: Set report level to 5, output to syslog
>     Apr 24 10:30:43 myth LCDd: Server forking to background
>     Apr 24 10:30:43 myth LCDd: Listening for queries on 127.0.0.1:13666
>     Apr 24 10:30:43 myth LCDd: CFontz: using Device /dev/ttyUSB0
>     Apr 24 10:30:44 myth LCDd: Key "Menu" is now reserved in exclusive mode by client [-1]
>     Apr 24 10:30:44 myth LCDd: Key "Enter" is now reserved in shared mode by client [-1]
>     Apr 24 10:30:44 myth LCDd: Key "Up" is now reserved in shared mode by client [-1]
>     Apr 24 10:30:44 myth LCDd: Key "Down" is now reserved in shared mode by client [-1]
>     Apr 24 10:30:44 myth LCDd: screenlist_switch: switched to screen [_server_screen]
>
>   This all looks "normal", no?  It's reading the correct config file (and the only LCDd.conf file that exists on the machine), it
> says it is forking to background, and it loads the specified driver, which connects to the proper device.  I still had to hit
> "Ctrl-C" to get back to the shell prompt, and never got the "[OK]" that the service had started up (usually shown by FC/RH as
> services are started/stopped/etc).  "ps ax | grep LCDd" indicated that the service had, indeed, started up and was running.

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?

Peter.