Nut 2.0.7 is not starting after boot - check config error

doktornotor

And you get exactly what blocked by Snort? There's a log for a reason.

joergH

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 snort

after waiting 5min, click on restart nut and its starting immediately

doktornotor

There sure like hell is extremely detailed Snort log showing what's blocked by what rule… Good luck.

joergH

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

doktornotor

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.

joergH

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 usage

ssh
mount -o rw /dev/ufs/pfsense0 /
cd /usr/local/pkg/
chmod777 nut.inc
mv nut.inc nut.inc.defekt
vi nut.inc

paste content from github

:wq
chmod..
mount -ro..
reboot

works fine.
thanks for help

joergH

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

it looks like there are missing rights or pointer to start_service("Nut") at nano boot…

doktornotor

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

joergH

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 picture

have you test the hole system ? a serial connected usv ?

i think you have not do that.

the older method for starting services work nice.

service.jpg_thumb

doktornotor

@joergH:

sorry, there are NO snort package installed.

Errrrrrr….

@joergH:

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.