[LCDProc] - Could not read config file



  • No matter what I do I can not get lcdproc to start. If I try to launch it from the services menu it just says "Stopped"

    Even after dropping to the shell, manually updating config file to reflect new lib paths, and trying to launch it with command line parms I get:

    
    [2.2-BETA][root@rt1.atx1.local]/usr/local/etc(305): ls -l
    -rw-r--r--  1 root  wheel   700 Nov  4 19:24 LCDd.conf
    
    [2.2-BETA][root@rt1.atx1.local]/usr/pbi/lcdproc-amd64/bin(282): ./LCDd
    Could not read config file: /usr/local/etc/LCDd.conf
    Critical error while processing settings, abort.
    
    [2.2-BETA][root@rt1.atx1.local]/usr/local/etc(290): LCDd -d curses -f -a 127.0.0.1 -p 13666 -u nobody -w 5
    Could not read config file: /usr/local/etc/LCDd.conf
    Critical error while processing settings, abort.
    
    [2.2-BETA][root@rt1.atx1.local]/usr/local/etc(291): LCDd -c null -d curses -f -a 127.0.0.1 -p 13666 -u nobody -w 5
    Could not read config file: null
    Critical error while processing settings, abort.
    
    

    I have no idea what else I can do to help and i'm not sure if it would fix these problems or not, but is it possible that lcdproc could get updated to the latest version, 0.5.7, as of this posting…



  • Which did you install LCDproc or LCDproc-dev?

    I don't have the HW to test properly, but the LCDproc-dev installed OK for me.  When I start it, it fails gracefully because it cannot find the bogus hardware I configured. Webgui gets it right, showing it's not running.

    But /usr/local/etc/LCDd.conf definitely exists, is readable, and has correct-looking content in my tests.

    Can 'cat /usr/local/etc/LCDd.conf'?

    I did notice that lcdproc does show up in the status_services.php page, but not in the services widget on the dashboard page.  <– seems it shows up on the widget if you tick 'enable at startup', but shows up in status_services in either case.

    Also, the latest seems to be 0.5.6 according to the links on the pfsense package page, not sure where you are seening 0.5.7.


  • Netgate Administrator

    0.5.6 is the latest lcdproc stable release but there is a 0.5.7 version avilable. It hasn't made it into a pfSense package yet though.

    When you first install the lcdproc package it will not run at all until you have configured both a hardware type and some screens. Doing that generates the rc files required to start it.

    Steve



  • @charliem:

    Which did you install LCDproc or LCDproc-dev?

    I have tried both versions in the pfsense package system.

    @charliem:

    Can 'cat /usr/local/etc/LCDd.conf'?

    
    Running ls -l /usr/local/etc/LCD*
    
    -rw-r--r--  1 root  wheel  627 Nov  8 14:32 /usr/local/etc/LCDd.conf
    -rwxr-xr-x  1 root  wheel  627 Nov  4 19:04 /usr/local/etc/LCDd.conf.orig
    
    Running LCDd
    
    Could not read config file: /usr/local/etc/LCDd.conf
    Critical error while processing settings, abort.
    
    Cat /usr/local/etc/LCDd.conf
    [server]
    DriverPath=/usr/local/lib/lcdproc/
    Driver=hd44780
    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
    ToggleRotateKey=Enter
    PrevScreenKey=Left
    NextScreenKey=Right
    ScrollUpKey=Up
    ScrollDownKey=Down
    [menu]
    MenuKey=Escape
    EnterKey=Enter
    UpKey=Up
    DownKey=Down
    [hd44780]
    driverpath=/usr/local/lib/lcdproc/
    ConnectionType=mplay
    Device=/dev/ugen1.2
    Port=0x378
    Speed=0
    Keypad=yes
    Contrast=850
    Brightness=800
    OffBrightness=0
    Backlight=yes
    OutputPort=no
    Charmap=hd44780_default
    DelayMult=1
    DelayBus=true
    Size=20x2
    
    

    @stephenw10:

    When you first install the lcdproc package it will not run at all until you have configured both a hardware type and some screens. Doing that generates the rc files required to start it.

    I've clicked and unclicked stuff in both tabs in the menu.. Nothing I do makes a difference when trying to launch LCDd..  :(

    Here are the screen shots of my configuration:
    http://i.imgur.com/Lg9oPD5.png and http://i.imgur.com/CNQOahW.png

    Edit:
    I've also tried this:

    
    [2.2-BETA][root@rt1.atx1.local]/usr/local/etc(62): LCDd -c LCDd.conf
    
    Could not read config file: LCDd.conf
    Critical error while processing settings, abort.
    
    [2.2-BETA][root@rt1.atx1.local]/usr/local/etc(63): cat LCDd.conf
    
    [Server]
    DriverPath=/usr/pbi/lcdproc-amd64/lib/lcdproc/
    Driver=text
    Bind=127.0.0.1
    Port=13666
    ReportLevel=5
    ReportToSyslog=no
    User=nobody
    Foreground=yes
    Hello="This is a"
    Hello="test!"
    WaitTime=4
    AutoRotate=yes
    ServerScreen=yes
    Backlight=on
    Heartbeat=on
    
    [text]
    Size=20x4
    
    

  • Netgate Administrator

    Are you running all of this on 2.2beta 64bit?

    Steve



  • Are you sure that's the right endpoint and device number?

    Can you increase the debug output level with "-r 5"?  (Do it on the command line; setting it in the config file won't work if the file is not found or processed correctly).

    Also, when you try running it from the command line, put in the full path to the config file with the -c argument.



  • @stephenw10:

    Are you running all of this on 2.2beta 64bit?

    Steve

    Yes.. 2.2 beta, 64bit…

    [2.2-BETA][root@rt1.atx1.local]/var/log(67): uname -a
    FreeBSD rt1.atx1.local 10.1-PRERELEASE FreeBSD 10.1-PRERELEASE #28 30e366f(HEAD)

    Version 2.2-BETA (amd64)
    built on Fri Sep 19 23:21:59 CDT 2014
    FreeBSD 10.1-PRERELEASE

    @charliem:

    Are you sure that's the right endpoint and device number?

    I've tried text, curses and the driver for my LCD and all give the same error…

    @charliem:

    Can you increase the debug output level with "-r 5"?  (Do it on the command line; setting it in the config file won't work if the file is not found or processed correctly).

    Also, when you try running it from the command line, put in the full path to the config file with the -c argument.

    It does not matter if I put anything on the command line or use full paths I still get the same "Could not read config file:"  Even when doing -r 5 on the command line I do not get any additional information. Seems to completely ignore what I tell it..



  • @djmixman:

    [2.2-BETA][root@rt1.atx1.local]/var/log(67): uname -a
    FreeBSD rt1.atx1.local 10.1-PRERELEASE FreeBSD 10.1-PRERELEASE #28 30e366f(HEAD)

    Version 2.2-BETA (amd64)
    built on Fri Sep 19 23:21:59 CDT 2014
    FreeBSD 10.1-PRERELEASE

    Long shot, but try a newer beta version.  Today's snapshot uses FreeBSD 10.1 Release; you are using an early prerelease, and there've been quite a few FreeBSD changes since then.  If you have the resources, you could see if you could duplicate the problem on a VM with either a fresh pfSense or a vanilla FreeBSD 10.1 image.


  • Netgate Administrator

    Ok, I've tested this using a recent snapshot and I was able to start it.
    How are you generating the LCDd.conf file?

    Steve



  • @stephenw10:

    Ok, I've tested this using a recent snapshot and I was able to start it.
    How are you generating the LCDd.conf file?

    Steve

    64 bit or 32?

    [2.2-BETA][admin@testbox.labbox]/root: LCDd -c /usr/local/etc/LCDd.conf
    Could not read config file: /usr/local/etc/LCDd.conf
    Critical error while processing settings, abort.

    My LCDd.conf file already existed and compares exactly to the one you attached in the hardware thread.


  • Netgate Administrator

    64bit.



  • Same here. latest 2.2 beta i386. Same error. recreated LCDd.conf by hand using vi. permission are ok. LCDd cannot read config file. Very weird.


  • Netgate Administrator

    Using the dev package?

    Steve



  • Yup.
    Need dev to drive the firebox display. Having said that, I tried the non dev version of the package. LCDd is same version and it cannot read the config file too. not in the /usr/local/etc directory or doesn't matter if I create the config anywhere else. Tried with the config created by pfsense and also recreated it from scratch using vi. even chmod 777 the file just to make sure it did not need write privileges on the file. My pfsense is i386 since it is on a firebox x-core-e.
    This is too bad as I have the firebox all tweaked up on 2.2. NICs blinking right, your fan control and status light program working like a charm and even IPV6 with 6RD now working. A working LCD is what is missing now.
    I read on a previous post of yours that it is working for you. Was it a new install? My is an upgrade from 2.1. It shouldn't matter though. I wonder if LCDd is using some weird library that is screwing things up.

    PS a big THANKS for the work you did to make a firebox an excellent pfsense platform for all of us


  • Netgate Administrator

    Hmm. I updated my xtm5 today and after a couple of reboots the LCD came back up. It's running 64bit though.
    I have the filesystem set to permanent read-write. I can't really see what bearing that might have here but it's an easy test.
    I'll have to fire up my test x550e and put 2.2 on it.

    Steve



  • If you have time, let me know how it goes. I am curious. I think it is a problem with the LCDd executable. Wonder if a fresh install would help. Although a fresh install vs update should not make any difference.


  • Netgate Administrator

    Ok, I upgraded my test X550e to todays snapshot (32bit obviously) 1G NanoBSD.

    [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: Thu Nov 27 01:06:40 CST 2014     root@pfsense-22-i386-builder:/usr/obj.i386/usr/pfSensesrc/src/sys/pfSense_wrap.10.i386  i386
    
    

    After the upgrade the lcdproc-dev package was not re-installed installed because it's not signed. I set the allow unsigned packages check and installed lcdproc-dev and rebooted. It came back up no problem. I did nothing else. That's suing the same LCDd.conf file and Shellcmd instructions that were carried across the upgrade from 2.1.5.

    It's working fine for me both 32 and 64bit.

    Are you still seeing this problem?

    Steve



  • Still having the problem. In my case the package was reinstalled after upgrade from 2.1 (after that deleted and reinstalled numerous times). Where do you set to allow unsigned packages? I didn't have to do that and maybe this is the problem.
    I am upgrading to Nov 27 snapshot so we are on the same version


  • Netgate Administrator

    It's in System: Advanced: Miscellaneous:
    If you don't have that checked it should fail the install in a pretty obvious way with authentication errors. The fact that yours didn't must surely be clue, or maybe that mine did. Perhaps you have a cached pbi? That shouldn't be possible on Nano though. Are you running Nano?

    Steve

    Edit: an obvious fail



  • Yes, I had the install unsigned package already checked. I guess it carried over from the upgrade.
    I am running nano 4gb i386.
    At this point I guess the only thing left is to try a fresh install. Don't know if it is going to help. My understanding is that all of the freebsd comes with the new nano image, configuration file get upgraded to the new version and packages get reinstalled during upgrade. No system software other than what is in cf/media get carried over. I am puzzled to say the least.



  • @jjstecchino:

    Where do you set to allow unsigned packages? I didn't have to do that and maybe this is the problem.

    Don't change that, the packages are signed. The installation would completely fail with a signature error if that were the issue.

    There is definitely some kind of issue with that package. I'm getting the same error that it can't find the config file, though it's there and permissions are such that it's readable by that process. I don't have anything with a LCD, not something I use.


  • Netgate Administrator

    Hmm, something very odd happening here. It definitely failed to install with an authentication error and then installed fine after I allowed unsigned packages. That was a few days ago though.
    It's definitely running fine now using whatever binary was installed by the update process when I went to todays snapshot.
    Both the machines I've tested this on were upgraded from 2.1.X so I don't know if I've got some hangover. I've never set a different package server but I guess that would do it.
    Further investigation required.  :-\

    Steve



  • Oh, some time back it could have. All PBIs were rebuilt within the past 3-4 days, there were some stragglers that hadn't been updated recently until then, and hence weren't signed. At this point, every PBI should be signed. I haven't found any that aren't.



  • lcdproc-dev is not signed. Maybe since it is a dev version it will never be.



  • Oh, sorry, indeed the dev version isn't signed.

    Is there a reason the dev version is an older lcdproc than the stable version? Seems odd.


  • Netgate Administrator

    When the dev version was created it was to add new drivers and update the lcdproc base version. At the time the existing package hadn't been updated for a while and was way behind the current lcdproc.
    If the original package has been updated it may be time to consolidate the two. The sdeclcd driver has been included upstream so it may already be in the original package. There were some changes made in the -dev package which seemed like a good idea at the time but in retrospect may not have helped.

    Steve



  • Well, did a fresh reinstall using today snapshot of nano 1gb on the x-core-e 550. setup lcdproc screen to use parallel interface, whatcguard sdeclcd driver, 2x20char line, lpt 4 bit wiring, setup a few screens, rebooted and service will not start. from command line same error. cannot read config file which is present and has correct permissions.
    I am scratching my head here.
    Stephenw10 did you do have any ideas? yours is working and I tried to duplicate your setup, down to the same size nano image.

    On a different note as I reinstalled fresh, the nano image does not have a config.xml in /conf and pf sense web gui will not start. I had to use the serial console, and manually copy config frpm /config.default to /config


  • Netgate Administrator

    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



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



  • 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.


  • Netgate Administrator

    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



  • @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.


  • Netgate Administrator

    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


  • Netgate Administrator

    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.



  • 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



  • 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


  • Netgate Administrator

    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



  • 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.


  • Netgate Administrator

    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



  • 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!



  • 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.