[LCDProc] - Could not read config file

stephenw10 · Dec 26, 2014, 12:00 PM

What did you update from/to? What method were you using to start lcdd?

Steve

Borage · Dec 28, 2014, 7:35 PM

The lcdproc_client.php does not even start after the last three updates. It looks like the client is unable to connect, but this is bullshit because the other client /usr/pbi/lcdproc-i386/bin/lcdproc works like a treat.

Hm, it looks like i also found a bug in the php file. :)

[2.2-RC][admin@pfsense.localdomain]/root: /usr/bin/nice -20 /usr/local/bin/php -f /usr/local/pkg/lcdproc_client.php

Warning: fsockopen(): unable to connect to localhost:13666 (Operation timed out) in /usr/local/pkg/lcdproc_client.php on line 915

Warning: stream_set_timeout() expects parameter 1 to be resource, boolean given in /usr/local/pkg/lcdproc_client.php on line 916

stephenw10 · Dec 28, 2014, 10:12 PM

Using the lcdproc or lcdproc-dev package? What hardware?

Steve

Borage · Dec 28, 2014, 10:54 PM

I use lcdproc-dev and my hardware is a Watchguard X1000. I found something strange in the file LCDd.conf, the path to the drivers seem to be wrong.

LCDd.conf

[server]
DriverPath=/usr/local/lib/lcdproc/
Driver=sdeclcd
Bind=127.0.0.1
Port=13666
ReportLevel=3
ReportToSyslog=yes
User=nobody
Foreground=no
ServerScreen=no
GoodBye="Thanks for using"
GoodBye="    pfSense     "
WaitTime=5
PrevScreenKey=Down
NextScreenKey=Up
[menu]
MenuKey=Left
EnterKey=Right
UpKey=Up
DownKey=Down
[sdeclcd]

It seems to work after I changed the path to the following. I rebooted my firewall several times and no problem whatsoever with the lcdproc_client.php.

DriverPath=/usr/pbi/lcdproc-i386/local/lib/lcdproc/

stephenw10 · Dec 28, 2014, 11:00 PM

I'm using /usr/local/lib/lcdproc/ and it's working fine. I'm not using the php client though.
The path to the driver cannot affect the client directly but it could stop the daemon running. Did you see the lcdproc server start?

Steve

Borage · Dec 28, 2014, 11:08 PM

I have no drivers in this path, only in /usr/pbi/lcdproc-i386/local/lib/lcdproc/. The lcdproc started, I can see that in the LCD display and with the ps command.

stephenw10 · Dec 28, 2014, 11:26 PM

I have no drivers there either. It shouldn't matter because the PBI system is supposed to take care of that. When you call the LCDd executable it is actually a link to file within the PBI subdirectories. From there the relative path results in the location you are entering.

Was LCDd starting before you changed the driver path?

Steve

Borage · Dec 28, 2014, 11:59 PM

My LCD started every time before i changed the path, except that the display showed zero screens (the LCD screen showed only LCDproc Server Cli: 0 Scr: 0).

The only problem for now, if the service dies I cannot simply restart it to get the displays back. In the previous pfSense version, I just ran the following script to solve the problem. Now I only get the message unable to connect to localhost:13666.

/usr/local/etc/rc.d/lcdproc.sh restart

stephenw10 · Dec 29, 2014, 2:24 AM

Have you read the rest of this thread where I talked about having to use a different startup procedure? I suspect that if you're still using the package method you probably have two copies of LCDd running on different ports one of which isn't responding.

Steve

Borage · Dec 29, 2014, 5:15 PM

Only one process when i ran this command.

[2.2-RC][admin@pfsense.localdomain]/root: pgrep -anx LCDd
70130

Something changed in one of the latest updates, now I cannot restart the service like before. The only way to get the screens back is to reboot pfsense.

[2.2-RC][admin@pfsense.localdomain]/root: /usr/local/etc/rc.d/lcdproc.sh restart
[2.2-RC][admin@pfsense.localdomain]/root: 
Warning: fsockopen(): unable to connect to localhost:13666 (Operation timed out) in /usr/local/pkg/lcdproc_client.php on line 915

Warning: stream_set_timeout() expects parameter 1 to be resource, boolean given in /usr/local/pkg/lcdproc_client.php on line 916

Borage · Dec 30, 2014, 5:47 PM

I disabled the firewall with the following command, but it is not possible to connect to localhost.

'pfctl -d

Everything works as expected after that I changed the LCDd daemon to listen on the LAN IP address and the client to connect to the same address.

Edit:

I permanently fixed the problem by editing the following file.

/usr/local/pkg/lcdproc.inc

	define('LCDPROC_HOST','localhost');
	define('LCDPROC_PORT','13666');

My changes: See line 36

	define('LCDPROC_HOST','127.0.0.1');
	define('LCDPROC_PORT','13666');

Topper727 · Jan 7, 2015, 5:53 AM

I made those code changes in /usr/local/pkg/lcdproc.inc and changes in the LCDd.conf file.

I am using LCDproc-dev

DriverPath=/usr/pbi/lcdproc-amd64/local/lib/lcdproc

This is where my drivers are in the 64 bit version.

When I start the service I get
Could not read config file: /usr/local/etc/LCDd.conf
Critical error while processing settings, abort.

but I have the file there. It has 644 permissions to the Proxy group

I get nothing back when I run pgrep -anx LCDd

I ran the service by
/usr/local/etc/rc.d/lcdproc.sh restart

and got
Could not read config file: /usr/local/etc/LCDd.conf
Critical error while processing settings, abort.

Warning: fsockopen(): unable to connect to 127.0.0.1:13666 (Operation timed out) in /usr/local/pkg/lcdproc_client.php on line 915

Warning: stream_set_timeout() expects parameter 1 to be resource, boolean given in /usr/local/pkg/lcdproc_client.php on line 916

If someone gets me the fix code I will put it into the version and have it merged so it will be updated for everyone

Borage · Jan 7, 2015, 9:10 AM

@Topper727:

When I start the service I get
Could not read config file: /usr/local/etc/LCDd.conf

For some reason the conf file must be located in the following path.

32-bit

/usr/pbi/lcdproc-i386/local/etc/

64-bit

/usr/pbi/lcdproc-amd64/local/etc

stephenw10 · Jan 7, 2015, 1:43 PM

More accurately you can put the conf file anywhere but /usr/local/etc because if you do LCDd will look in the wrong place. This appears to be an issue with the pbi packaging.

Steve

Topper727 · Jan 15, 2015, 6:16 AM

Has someone started to work on this or not.. I wish I had this working.. if working i might spend some effort to make some new features for it

Topper727 · Jan 18, 2015, 4:55 AM

BUMP

stephenw10 · Jan 18, 2015, 6:54 PM

Not much motivation since it works fine if you don't use the php client and move the config file, which is how I'm running it. ;)

Since this appears to be a PBI problem do we have a link to some PBI docs? pfSense is moving away from PBIs in the future so it may be solved by that anyway.

Steve

Topper727 · Jan 20, 2015, 5:30 PM

Made some changes to the LCDproc.inc file and it works now on 64 bit.

https://github.com/topper727/pfsense-packages/commit/2cd89f970053f4bf0fa23d0b88f50e69ab68f410

I hope someone can bump the version number as I not skilled at that yet

I can even make changes in UI page and the screen will restart and show the things I that I changed like I want

phil.davis · Jan 20, 2015, 5:17 PM

@Topper727:

Made some changes to the LCDproc.inc file and it works now on 64 bit.

https://github.com/topper727/pfsense-packages/commit/2cd89f970053f4bf0fa23d0b88f50e69ab68f410

I hope someone can bump the version number as I not skilled at that yet

I expect you will need code to set LCDPROC_CONFIG differently depending on the pfSense version, so that the package will still also work on older pfSense versions.
e.g. Bandwidthd does tests to "Check pfSense version" from line 31 of:
https://github.com/pfsense/pfsense-packages/blob/master/config/bandwidthd/bandwidthd.inc

Set a constant with define() and use it further down to substitute the path as needed.

Also, why do you need to add the "address of" "&" in various function parameters?

The version bump is just a matter of editing the files at:
https://github.com/pfsense/pfsense-packages
like:
pkg_config.10.xml
pkg_config.8.xml
pkg_config.8.xml.amd64

Search for lcdproc and see where the version is - increment the last number.

Topper727 · Jan 20, 2015, 9:09 PM

The & was in my config.. not sure if I did while back or was part of a update that I got. Either way that worked. But yes you have point since the package points to amd 64 locations that would cause issue with i386 and older versions as I think they have different file structure

My skills are limited.. Hope someone will help with this.

And my time is limited also..

Found Jim-p did that & stuff to the file little while ago
https://github.com/topper727/pfsense-packages/commit/a890380266da7f589b809701bd3d0e8ac715e82f