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 service

    Ok, 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 save

    please help

    joergH


  • Banned

    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: exiting

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


  • Banned

    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 snort

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


  • Banned

    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


  • Banned

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



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


  • Banned

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



  • Banned

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