Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Nut 2.0.7 is not starting after boot - check config error

    Scheduled Pinned Locked Moved pfSense Packages
    14 Posts 2 Posters 2.0k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • J
      joergH
      last edited by

      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

      1 Reply Last reply Reply Quote 0
      • D
        doktornotor Banned
        last edited by

        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

        1 Reply Last reply Reply Quote 0
        • J
          joergH
          last edited by

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

          1 Reply Last reply Reply Quote 0
          • J
            joergH
            last edited by

            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.

            1 Reply Last reply Reply Quote 0
            • D
              doktornotor Banned
              last edited by

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

              1 Reply Last reply Reply Quote 0
              • J
                joergH
                last edited by

                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

                1 Reply Last reply Reply Quote 0
                • D
                  doktornotor Banned
                  last edited by

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

                  1 Reply Last reply Reply Quote 0
                  • J
                    joergH
                    last edited by

                    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

                    1 Reply Last reply Reply Quote 0
                    • D
                      doktornotor Banned
                      last edited by

                      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.

                      1 Reply Last reply Reply Quote 0
                      • J
                        joergH
                        last edited by

                        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

                        1 Reply Last reply Reply Quote 0
                        • J
                          joergH
                          last edited by

                          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…

                          1 Reply Last reply Reply Quote 0
                          • D
                            doktornotor Banned
                            last edited by

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

                            1 Reply Last reply Reply Quote 0
                            • J
                              joergH
                              last edited by

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

                              1 Reply Last reply Reply Quote 0
                              • D
                                doktornotor Banned
                                last edited by

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

                                1 Reply Last reply Reply Quote 0
                                • First post
                                  Last post
                                Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.