[LCDProc] - Could not read config file
-
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
-
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.confSo 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/LCDdIt 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
-
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) = 7417069cc4304f776d9c64e12c55ec97When 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.
-
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) = cf735ce4045190e52f00a2755e80b6cfTry 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.
-
even more interesting. 64 or 32 bits?
-
64bit
-
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 i386After 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 5Gives 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:13666I 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
-
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?
-
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!
-
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.
-
So Stephen what is your suggested configuration? copy LCDd.con to /conf and what else?
What do you start in shellcmd other than LCDd?
Any other configuration files to place in /conf?On a different note, the only thing that do not survive an upgrade are the msk and sk modules for the nic led, any suggestion on making them persistent after an upgrade? I guess I can place a cp command in shellcmd and perform an additional reboot after an upgrade but it is not very elegant.
Also since you are the firebox guru, I wanted to mention a possible new problem with freebsd 10 and the mask nic. I used one of the msk nic on both of my firebox as a sync interface for carp. On 2.1 I had to add hw.msk.msi_disable=1 on loader.con.local and everything was good. On fobs 10 with or without mis disable both boxes would hang. nothing in the logs or no kernel errors. As I switched the sync interface to one of the sk nic I had no crashes anymore. I did that because I had the sense that crashes would happen when larger data chunks were getting transferred (i.e. dhcp or dans syncs)
-
Basically it's this:
http://forum.pfsense.org/index.php/topic,7920.msg344513.html#msg344513
You can see in the screenshot in that post what other stuff I have running.The modified kernel modules do not survive a firmware update for good reason. If the base FreeBSD version is changed then loading bad kernel modules could potentially render the box unable to boot. I usually store a copy of the modules in /conf so I can easily copy them back. Not having them load is largely aesthetic anyway. Also running lcdproc like I do requires a second reboot anyway because the package reinstalls at the first boot but after the shellcmd scripts are run so never starts on the first boot. Not great but, again, much better then having it crash out every few days or having to completely manually install it each time. ;)
I guess it would be relatively easy to put in a shellcmd that is something like; if /boot/modules/sk and msk don't exist then copy from /conf and reboot. The risk at a kernel update is low, it would probably just fail to load the modules, but is there. Let us know if you create such a command.Interesting about the msk lockups. Was that running the modified msk module? The previous issues that caused them to become unresponsive always triggered 'watchdog timeout' errors in the system logs. If you have nothing it's going to be hard to track down. They worked fine in the same config under 2.1.5? You could try booting in verbose mode, keeping the serial console open (or recording it's output) and forcing the issue. :-
There are a whole lot of changes in msk between 8.3rel and 10.1rel. Some in Rx checksum off load. You could try disabling any hardware offloading that is set.
You could try one box using sk and the other using msk to try to determine which half of the carp pair is causing the problem. Not sure what that might tell us though.Steve
-
Thank you for pointing me to the lcdproc post.
Regarding the msk kernel module I had the problem with the unmodified and modified one.
This is the extent of my test as now.Tried with both boxes with sync interface on msk3, wan on sk0, and an on sk1. This was my working setup on 2.1.5. Can ping boxes back and forth without errors or freezes.
I was reconfiguring my boxes from scratch, both on 2.2. Did basic setup on both, then started carp and update nat rules, dhcp static leases and dns forwarder, host overrides on one box and having them synced on the other.
With every update the boxes kept on crashing. this had me puzzled. Then I started getting XMLRPC can't connect… error on the notification area on the master. XMLRPC was working previously with items synced to the second box. rebooted everything and retried. Could not get rid of the XMLRPC can't connect... error, checked firewall rules, ability to ping etc. and everything appeared fine as noting was changed from previously working setup. So I pulled the cf and reimaged them and restarted from scratch. same deal happened. XMLRPC worked for a little bit, then crashes and finally XMLRPC can't connect error. I went through this iteration a few times. The confusing element could be that I was also trying to work on LCDd and setting the nic led drivers. I went through this process at least once with the original nic drivers and at least a couple of times with the modified nic led drivers. at least once without the msk.msi disabled and all other time with the disable line in loader.config.local. Interesting both boxes would crash almost simultaneously. Hard crash, nothing working until reboot, webgui freezed, serial console freezed, ssh freezed.The last time I tried with the master sync interface on sk3. got similar problem but only the backup firebox would crash. I started again getting XMLRPC can't connect errors and thats when the backup boxes was crashed.
I then moved sync on sk3 on the second box and since then no more crashes, no XMLRPC can't connect errors and I was able to complete my reconfig on both boxes.Now they are both running 2.2, carp and XMLRPC is perfectly functional, LCDd is working on both with the freebsd package overwriting the lcdproc-dev symbolic links with its executables, modified nic led drivers on both boxes. your fan and green led program on. Uptime is 36h without errors or crashes.
My conclusion is msk driver on freebsd 10 is even more screwed up then it was in 8.3 but I may be wrong. Fortunately sk seems to be in good working order. I initially used msk3 because it was convenient for me to use the last nic port on the box for sync.
I'll be glad to do some tests on msk but I don't know what tunable I need to modify. I guess I can run an iperf between the 2 boxes generating a lot of traffic and see if it crashes or not.
It would be great to be able to use the lcdproc package straight so I don't have to download pkg, and lcdproc with every upgrade. I am going to try your solution with shellcmd that is definitely less aggravating then mine. It is puzzling that LCDd from pfsense can read a config file from /conf but not from /usr/local/etc. I wonder why it is doing it?
How do I get my hands on the lcdproc-dev source? I would like to try to update lcdproc to 0.5.7 and go through the LCDd source to try to understand. Do I need any special tools to compile? Can I just setup a freebsd 10 on vmware and compile to recreate the package? I think I remember reading you need some tools from a restricted repository but I am not sure.
-
It is puzzling that LCDd from pfsense can read a config file from /conf but not from /usr/local/etc. I wonder why it is doing it?
Indeed it is. I suspect it's something to do with the PBI system that I don't understand. The location /usr/local/etc seems to be significant in that it's written to by the pbi system. When you call LCDd at /usr/local/sbin it sees a symlink to /usr/pbi/lcdproc-i386/bin….. but the file there is just a place holder of some sort linked to the real file location in /usr/pbi/lcdproc-i386/local/sbin. I'm clearly guessing here but I suspect the various file linking may have the executable looking for the conf file in /usr/pbi/lcdproc-i386/local/etc. Or something like that. ;) It would be easy to do with a bad path. It doesn't seem to distinguish between a bad conf file and no conf file at all. Though I've not tried a deliberately bad file.
How do I get my hands on the lcdproc-dev source? I would like to try to update lcdproc to 0.5.7 and go through the LCDd source to try to understand. Do I need any special tools to compile? Can I just setup a freebsd 10 on vmware and compile to recreate the package? I think I remember reading you need some tools from a restricted repository but I am not sure.
The pfSense packages repo is not restricted it's on the pfSense github:
https://github.com/pfsense/pfsense-packagesIt's a long time since I tried to build a package (and failed!), before the pfsense-tools repo restriction came into being and before the switch to pbis. I'm not sure if you need the tools repo or not. Probably not to just generate a package but maybe to get it submitted upstream where all binaries are built by the pfSense build system. You could just message mdima and ask about updating it. Is there some specific reason to update to 0.5.7? 0.5.6 is most recent stable release.
Steve
-
Yep, that is the issue. If you put the conf file in:
/usr/pbi/lcdproc-amd64/local/etc(or i386 deppending on your architechture) LCDd runs no problem.
Steve
