Nut 2.0.7 is not starting after boot - check config error
-
After Upgrade NUT (2.0.5) to 2.0.7 service don't start after boot:
Log shows->
php-fpm[287]: /rc.start_packages: [nut] ERROR: Service failed to start: check configuration.
php-fpm[287]: /rc.start_packages: [nut] INFO: Starting serviceOk, But:
If i start the Service by clicking on the service tab or login/ssh it starts without any problem.
Version 2.2.4-RELEASE (i386)
built on Sat Jul 25 19:56:41 CDT 2015
FreeBSD 10.1-RELEASE-p15
Platform nanobsd (2g)Local apc usv
have test as follows:
-deinstall package, reboot, install package
-reconfig and saveplease help
joergH
-
Did you check it's really NOT running? I will remove that log entry. It's a useless noise, nut takes quite some time to start, esp. with networked UPS; this logs immediately after launching the service, misleading logspam.
https://github.com/pfsense/pfsense-packages/pull/1019
-
@doktornotor
No, service not running.
-After Upgrade to version 2.0.8 same, without check config message in Log.Log shows:
php-fpm[287]: /rc.start_packages: [nut] INFO: Starting service
..
apcsmart[3179]: Startup successful
apcsmart[3179]: Signal 15: exitingafter click restart service on service tab or change/save config its starting:
Log shows:
apcsmart[69403]: Startup successful
upsd[69521]: listening on ::1 port 3493
upsd[69521]: listening on 127.0.0.1 port 3493
upsd[69521]: Connected to UPS [USV1]: apcsmart-USV1
upsd[71360]: Startup successful
upsmon[73625]: Startup successful
upsd[71360]: User monuser@127.0.0.1 logged into UPS [USV1] -
i am using snort:
after disable "block offenders" in snort, nut starts (@reboot) without any problem.
no logs shows, that snort block local traffic.
its a snort bug ? local traffic should auto whitelisted.
-
And you get exactly what blocked by Snort? There's a log for a reason.
-
no log shows-> log did not show any, sorry, my bad english
i have made a new install on a fresh drive, reload backup config, install nut and snort
packages. disable snort, reboot - nut dont start. i am wrong with snortafter waiting 5min, click on restart nut and its starting immediately
-
There sure like hell is extremely detailed Snort log showing what's blocked by what rule… Good luck.
-
usv is serial connected.
->make a fix to: "remove log entries confusing users" is not that great help.
->nut errors began after "code style fixes.."
best regards
joergH -
I already explained above why I removed that. So yeah, the logs were confusing users. I am using this package on multiple boxes and all of those had this useless, confusing noise logged, despite NUT starting perfectly fine. Simply because when the check is done, it's bound to fail. Provides zero useful info to users.
Plus, this clearly has absolutely nothing to do with NUT and everything to do with your box messed up by Snort.
-
i don't no why or what, but since last code style changes it does not start.
im testing many times, install fresh on my machine. i am tired.here is my fix:
copy the old (working) nut.inc from github:
rbgarga on May 5 - Declare pfs_version as global on first usagessh
mount -o rw /dev/ufs/pfsense0 /
cd /usr/local/pkg/
chmod777 nut.inc
mv nut.inc nut.inc.defekt
vi nut.incpaste content from github
:wq
chmod..
mount -ro..
rebootworks fine.
thanks for help -
find the problem in nut
after code style fix the way to start service is changed in nut.inc:
a function with mwexec is deleted without replacement, the start call renamed:deleted:
49- function nut_action ($action) {
50- if (file_exists(NUT_RCFILE))
51- mwexec(NUT_RCFILE.' '.$action);
52- }renamed:
524- nut_action('start');to:
522+ start_service("nut");Fix:
copy back the function and rename the call to nut_action.
tested on PFSense 2.2.4 nano 2g 4g nut 2.0.8it looks like there are missing rights or pointer to start_service("Nut") at nano boot…
-
Yeah. start_service("nut") is the correct way to do things and there's no problem with that on any sane box. Not to mention, here's the snippet from /etc/inc/service-utils.inc:
function start_service($name) { global $config; if (empty($name)) return; if (is_array($config['installedpackages']) && is_array($config['installedpackages']['service'])) { foreach($config['installedpackages']['service'] as $service) { if(strtolower($service['name']) == strtolower($name)) { if($service['rcfile']) { $prefix = RCFILEPREFIX; if (!empty($service['prefix'])) { $prefix =& $service['prefix']; } if(file_exists("{$prefix}{$service['rcfile']}") || is_link("{$prefix}{$service['rcfile']}")) { mwexec_bg("{$prefix}{$service['rcfile']} start"); } } if (!empty($service['startcmd'])) eval($service['startcmd']); break; } } } }
So, to sum that up, what it does is exactly the same what that nut_action() reinvented wheel was doing, just in background.
mwexec_bg("{$prefix}{$service['rcfile']} start");
This is not a package bug. If you want to debug something, start with the service-utils.inc stuff above and interaction between other services getting started on boot. The basic assumption here is: Snort takes ages to start on your box (hardly surprising on some nanobsd box with slow media). Snort/Suricata starts in backgroup as of recent versions as well.) Until that starts, other services are delayed.
Note: You might be able to work around that issue by reinstalling Snort. That will make it start after nut. (This workaround will last until you reinstall nut after Snort.)
-
sorry, there are NO snort package installed.
nut don't start at boot, ->package 2.0.9 installed
->NUT is enabled, however the service is not running!
to clarify, look at the picturehave you test the hole system ? a serial connected usv ?
i think you have not do that.
the older method for starting services work nice.
-
sorry, there are NO snort package installed.
Errrrrrr….
i am using snort:
after disable "block offenders" in snort, nut starts (@reboot) without any problem.Dude. I'm done here. As for the package itself, there's nothing to fix. If mwexec("/usr/local/etc/rc.d/nut start") works for you and mwexec_bg("/usr/local/etc/rc.d/nut start") - which is what start_service("nut") translates to - does not, the issue is obviously not the package code here.
BTW, I would recommend to reinstall your box from scratch. Keeping it mounted RW all the time as noted in 2.2.4 release docs errata would probably help as well.