[LCDProc] - Could not read config file

stephenw10

Left the box at what passes for an office. ;) So I can't check right now. I'll get the md5 sum on the binaries tomorrow.
The only thing I can think is that on my 64bit box I have the filesystem set to permanently read-write. This was a hang over from a much earlier snapshot where remounting it RO was causing a huge delay. However i'd dismissed that as a cause because the 32bit box is not set to RW. However whilst checking something else out I found that it's actually leaving the filesystem mounted RW for some reason. Now I don't know why it should make any difference. LCDd shouldn't be writing anything. I could just about imagine it's trying to copy the config file but I don't know why. Anyway it's easy to test it by setting the filesystem permanently RW in Diagnostics: Nanobsd:

Steve

jjstecchino

Tryied filesystem rw permanent does not make any difference. I am about to give up on this.

jjstecchino

SOLVED (sort of)

lcdproc-dev needs to be updated.
installed lcdproc 0.5.7_1 on top of lcdproc-dev and now it works flawlessly.

For whoever is interested in a step by step temporary solution until lcdproc-dev is up to date:

Install lcdproc-dev 0.5.6 from pakages
drop to freebsd console
mount -uw /
pkg install sysutils/lcdproc
go to GUI status/services and start lcdproc

it should work

In /usr/local/sbin and /usr/loca/bin there are symbolic links to /usr/pbi/lcdproc/sbin and bin pointing to LCDd, lcdexec and lcdproc. installing the freebsd package overwrite these links with the downloaded executables. The php file handling lcdproc fortunately refers to the standard location in /usr/local/… so it is pointing to the new files. So just installing the freebsd package on top of the old pfsense lcdproc-dev pakage works flawlessly.

Yeah! Working firebox with PFSense 2.2, IPV6 and working LCD. Cant be happier.

Now time to learn the intricacies of ipv6.

stephenw10

Nice discovery. Leaves me puzzled as to why my install is working though. I don't remember them being symlinks. I'll check tomorrow. Maybe if you had copied the older version it would have also worked. :-\

Steve

jjstecchino

@stephenw10:

Nice discovery. Leaves me puzzled as to why my install is working though. I don't remember them being symlinks. I'll check tomorrow. Maybe if you had copied the older version it would have also worked. :-\

Steve

I think I tried that a couple of days ago when I was playing with permissions. I think I copied the lcdproc executables from the pbi dir to usr/local and it was a no go. At this point I believe it may be a problem with LCDd using libraries maybe incompatible with FreeBSD 10.
Maybe on your install you are using other plugins that have updated some of the common libraries and that's why lcdproc works for you.

Well isn't it time to upgrade lcdproc to the latest release anyway? How do we contact the lcdproc-dev maintainer? It should be a simple upgrade to do as the php code works untouched.

stephenw10

If this is just a matter of updating the lcdproc version then just try installing the original lcdproc package which is now at 0.5.7-1. Even if the sdeclcd driver isn't there (it might be since it's in lcdproc upstream now) you should still be able to set a driver and start LCDd. It should be able to open the conf file. However I'm back here at my test box this morning and I misremembered, I do have symlinks to the lcdproc binaries. All three point to /usr/pbi/lcdproc-i386/bin though. Don't know if that's relevant , probably not since the sbin directory is a symlink to bin.
Anyway I'm still at a loss to explain why my box is running it just fine. :-\

[2.2-BETA][root@pfSense.localdomain]/usr/pbi/lcdproc-i386/bin: ./LCDd -h
LCDd - LCDproc Server Daemon, 0.5.6

Copyright (c) 1998-2012 Selene Scriven, William Ferrell, and misc. contributors.
This program is released under the terms of the GNU General Public License.

Usage: LCDd [<options>]
  where <options>are:
    -h                  Display this help screen
    -c <config>Use a configuration file other than /usr/local/etc/LCDd.conf
    -d <driver>Add a driver to use (overrides drivers in config file) [curses]
    -f                  Run in the foreground
    -a <addr>Network (IP) address to bind to [127.0.0.1]
    -p <port>Network port to listen for connections on [13666]
    -u <user>User to run as [nobody]
    -w <waittime>Time to pause at each screen (in seconds) [4]
    -s <bool>If set, reporting will be done using syslog
    -r <level>Report level [2]
    -i <bool>Whether to rotate the server info screen
Critical error while processing settings, abort.
[2.2-BETA][root@pfSense.localdomain]/usr/pbi/lcdproc-i386/bin: md5 LCDd
MD5 (LCDd) = 7417069cc4304f776d9c64e12c55ec97
[2.2-BETA][root@pfSense.localdomain]/usr/pbi/lcdproc-i386/bin: md5 lcdproc
MD5 (lcdproc) = 7417069cc4304f776d9c64e12c55ec97</bool></level></bool></waittime></user></port></addr></driver></config></options></options>

Are you running a clean install? Both my boxes are updates from 2.1.X.

Steve

stephenw10

Theory: LCDd cannot read the conf file because it is somehow locked by a previously run instance of LCDd. Your box is setup to run LCDd using the package rc script which is notoriously bad at starting cleanly. I am using Shellcmd scripts.
Try running with report level 5 (-r 5) at the CLI.

This doesn't explain why updating the binary solves the issue though.

jjstecchino

OK the mystery gets thicker…..at least for me. somebody more knowledgeable may shed some light.

removed freebsd package, then removed pfsense lcdproc-dev. Clean slate now.

Installed pfsense lcdproc wich is 0.5.7_1, same version as freebsd pkg.

setup driver to curses, setup some screens ----> no go.

Start LCDd from console: /usr/local/sbin/LCDd -c /usr/local/etc/LCDd.conf --> bombs saying cannot read config file.
Starting LCDd executable from pbi/..../bin directory --> same result as above.

Install freebsd lcdproc pkg. symlinks on /usr/local/sbin and bin get overwritten by pkg executables.

Start freebsd LCDd executable from /usr/local/sbin/LCDd -c /usr/local/etc/LCDd.conf --> All OK. reads config and just work.

Now are the 2 executables same?

MD5 (/usr/pbi/lcdproc-i386/bin/LCDd) = ebbd43300381f0291d6deddc9e4c97b9 (pfsense)
MD5 (/usr/local/sbin/LCDd) = 4061ed254181a5a518bcafcbc8695810 (freebsd)

No they are not. Now is it a library problem?

Overwrite /usr/local/sbin/LCDd (freebsd) with /usr/pbi/lcdproc.../bin/LCDd and keep everything else equal
Run LCDd from /usr/local/sbin/LCDd --> complains it cannot find LCDd.pbiopt
copy LCDd.pbiopt from /usr/pbi/lcdproc.../bin to /usr/local/sbin
Try to run LCDd again --> original error that cannot read config file in /usr/local/etc/LCDd.conf

So we have come full circle.

My conclusions at this point (probably flawed by my lack of knowledge about the pbi package system)

Not a library problem, don't think LCDd uses any special library other than the different drivers

freebsd and pfsense LCDd same version but compiled with different compiler options or code to support pbi (probably same compiler options/code used on lcdproc-dev and this is why they are suffering from the same problem)

Now I dont know anything about PBI and I dont know the function of the pbiopt file. My has the following lines.

cat LCDd.pbiopt
PROGDIR: /usr/pbi/lcdproc-i386
TARGET: sbin/LCDd

It would seem something describing the location of the executable. in my PBI installation of lcdproc /usr/pbi/lcdproc.../sbin is a symbolic link to the bin directory.
I wonder if the pbi version of lcdproc uses the information from pbiopt and in some ways screws up the relative path to the config file even if it is specified by the c option.

Just speculations on my end at this point as I will have to read about building pbi packages and experiment. My understanding is that to build packages you need access to the super secret tool repository which I dont have. Otherwise I would take a stab at playing with the package to make it work.

Back to the freebsd package for now

jjstecchino

Still cant understand why Stephen install works. Mine did not work after an upgrade from 2.1.5 and did not work after a fresh install of the Nov30 2gb nanobsd version. Maybe there is an issue with pbi permissions that in some way are different between my install and Stephen

stephenw10

Yes, odd. One thing that might be a factor is that uninstalling and then reinstalling a package does not remove the package config scetion from the config file. The fact that I had this installed and running in 2.1.5 before ungrading to 2.2 seems significant.
Looking back at my MD5 sums above for the 0.5.6 pbi binaries I thought I made some error because the files LCDd and lcdproc are the same file! Also lcdexec is the same file. :o Also they are only 9k which seems way too small. My own tiny program is bigger than that.
I don't understand the pbi package system either.

[2.2-BETA][root@pfSense.localdomain]/usr/pbi/lcdproc-i386/bin: md5 LCDd
MD5 (LCDd) = 7417069cc4304f776d9c64e12c55ec97
[2.2-BETA][root@pfSense.localdomain]/usr/pbi/lcdproc-i386/bin: md5 lcdproc
MD5 (lcdproc) = 7417069cc4304f776d9c64e12c55ec97
[2.2-BETA][root@pfSense.localdomain]/usr/pbi/lcdproc-i386/bin: md5 lcdexec
MD5 (lcdexec) = 7417069cc4304f776d9c64e12c55ec97

When it can't read the file did you try starting it at report level 5?

Steve

jjstecchino

Stephen on my first attempt I also upgraded from 2.1.5 where lcdproc was working just fine and did not work. I then did a fresh install and did not work either. I think the data in config.xml is used to write the real LCDd.conf file in /usr/etc. What is interesting is that leaving everything in the configs equal except for using the freebsd LCDd executable makes it work. This is why I think the problem is with the executable and may have to do with some built in security on the pbi version that get bypassed by the freebsd LCDd. Again I dont know much about building pbi's so just speculation.

stephenw10

Ah, so those files are not actually the executables. The real files are:

[2.2-BETA][root@pfSense.localdomain]/usr/pbi/lcdproc-i386/local/bin: md5 lcdproc
MD5 (lcdproc) = 2ec55b6ee3598d850bde73aa40d65bc4
[2.2-BETA][root@pfSense.localdomain]/usr/pbi/lcdproc-i386/local/bin: md5 lcdexec
MD5 (lcdexec) = 2b7e6ad087f87b86fb44b5fb69731b82
[2.2-BETA][root@pfSense.localdomain]/usr/pbi/lcdproc-i386/local/sbin: md5 LCDd
MD5 (LCDd) = cf735ce4045190e52f00a2755e80b6cf

Try moving those. And try a high reporting level if it still fails.

Steve

jjstecchino

Tried to move those and gives the same error. Interesting it seems just LCDd to be problematic. lcdproc and lcdexec seem to do fine unchanged.

Now wrestling with another issue. I cant upgrade to a new snapshot. The beauty of running betas… Fun though!

chpalmer

The LCD package is also working on my 2.2 testbox (XTM 5 Series) after following your guide Steve.

Im running on a 4G CF and cannot remember if I ever had 2.1.x on it but don't believe I did. I don't mind yanking the card and starting over if needed.

jjstecchino

even more interesting. 64 or 32 bits?

chpalmer

64bit

stephenw10

OK I'm back home after being away for a week and restricted to just one test box and forgot my USB/serial adapter. ::)

So I've flashed a card with a clean Nano image in my X550e.

[2.2-BETA][root@pfSense.localdomain]/root: uname -a
FreeBSD pfSense.localdomain 10.1-RELEASE FreeBSD 10.1-RELEASE #0 29f4af5(releng/10.1)-dirty: Tue Dec  2 00:20:42 CST 2014     root@pfsense-22-i386-builder:/usr/obj.i386/usr/pfSensesrc/src/sys/pfSense_wrap.10.i386  i386

After installing added WGXepc, because otherwise the fans drive me insane. Then enabled SSH, allowed unsigned packages, added an allow all rule on WAN, copied the LCDd.conf file attached above to /conf and added the shellcmd package.
Then I installed the lcdproc package and then uninstalled it because it doesn't include the SDECLCD driver.
Then I installed the lcdproc-dev package.
It started no problems, it behaves exactly as I would expect.

Without specifying a conf file:

[2.2-BETA][root@pfSense.localdomain]/root: LCDd -r 5
LCDd version 0.5.6 starting
Built on Apr 22 2014, protocol version 0.3, API version 0.5
Using Configuration File: /usr/local/etc/LCDd.conf
Could not read config file: /usr/local/etc/LCDd.conf
Set report level to 5, output to stderr
Critical error while processing settings, abort.

Specifying a conf file:

[2.2-BETA][root@pfSense.localdomain]/root: LCDd -c /conf/LCDd.conf -r 5

Gives logs:

[2.2-BETA][root@pfSense.localdomain]/root: clog /var/log/system.log | grep LCDd
Dec  2 23:47:34 pfSense LCDd: LCDd version 0.5.6 starting
Dec  2 23:47:34 pfSense LCDd: Using Configuration File: /conf/LCDd.conf
Dec  2 23:47:34 pfSense LCDd: Listening for queries on 127.0.0.1:13666

I didn't setup anything using the lcdproc gui pages

I am at a loss to explain why it won't run for you. :-\

Do you have anything in /usr/local/etc/rc.d? If you enable lcdproc via the gui you get an lcdproc rc file there, perhaps that is being called? Hard to see why though.

Steve

jjstecchino

Hold on…. here you are doing something different I have to try.
You are copying a LCDd.conf into /conf and staring LCDd pointing to that config. I have not tried that.
From What I have seen, the lcdproc pfsense package saves and updates the LCDd.conf file in /usr/local/etc/LCDd.conf. If I recall correctlyit launches LCDd with /usr/bin/nice 20 /usr/local/sbin/LCDd -c /usr/local/etc/LCDd.conf.

Why did you save a config in /conf?

jjstecchino

Interesting… if I copy the same LCDd.conf from /usr/local/etc to /conf and I run -c from there it works but if I launch with -c to /usr/local/etc/LCDd.conf it doesnt!

stephenw10

@jjstecchino:

Why did you save a config in /conf?

Because when using the sdeclcd driver it's almost impossible to get the package to start reliably. Something in it can't cope with the multiple package restarts at boot and you usually end up with just LCDd running and no client but I've also seen two LCDds or just the client. ::) I spent a fair few hours trying various modifications to the start script but in the end gave up. Even when it would start with the correct number of clients and servers it would crash after a day of so the next time the packages were restarted. I start the server and client using shellcmd entries and it works perfectly. Putting the conf file in /conf means it survives a firmware update.

This is interesting. I suggest it's looking in the wrong place. Maybe there isn't a full path being used somewhere. Does it give you anything more useful with '-r 5'?

Steve

Edit: You can read about the many things we tried starting from about here.