[Nut-upsuser] FC4 + nut => shutdown sequence conundrum

[Miguel]

Summary
=======

I have encountered problems with the nut shutdown sequence using the
directory structure in the packages for Fedora Core 4.

These problems occur when the /var file system is mounted as a separate
volume.

I have done some investigation and think that I have an answer, but I need
verification from someone who has more experience from nut on a wider
variety of systems.

I want to assist in getting this issue resolved.


Detail
======

I have been successfully testing nut on a relatively simple system.

  Fedora Core 4
  nut 2.0.2 rpm packages from rpmfind.net

I have been using the .rpm packages for Fedora Core 4 because they
generally do a good job of managing the startup and shutdown sequences.

My issue is this ...

When I moved to a 'production' system I found that the system would not
power off the UPS when a

  # upsmon -c fsd

was given.

Investigation revealed the following:

 /var/run/ups was not mounted, so 'upsdrvctl shutdown' failed.


On production systems I generally mount /var as a separate volume.
However, in /etc/rc.d/init.d/halt the /var filesystem gets unmounted
before the test for /etc/powerkill ... so 'upsdrvctl shutdown' fails.

The /etc/sysconfig/ups config file for Fedora contained some references to
a particular driver and serial port. This data is redundant with the
information in ups.conf, so I have been using upsdrvctl instead of the
specific driver name in /etc/sysconfig/ups

I thought that perhaps by putting in the specific driver+device names in
/etc/sysconfig/ups that this would allow the UPS to shut down without
having access to /var/run/nut ... no joy. It turns out that
/sbin/cyberpower also requires access to /var/run/nut ... so the system
still will not shut down.


So, it looks to me like I am stuck.

 * I need to have /var as a separately mounted volume
 * that volume will be unmounted by the time the driver runs
 * the driver wants to have access to /var/run/nut

One answer might be "do not mount /var", but this is not a viable answer
for production systems where /var/spool and /var/mail can grow and
potentially consume the entire volume.


Looking at the source code for drivers/main.c I observe that the chdir is
happening in main() on line 551. The call to shutdown the UPS happens a
few lines later, on line 568. The interesting lines are:

        if (chdir(dflt_statepath()))
                fatal("Can't chdir to %s", dflt_statepath());

        setup_signals();

        /* clear out callback handler data */
        memset(&upsh, '\0', sizeof(upsh));

        upsdrv_initups();

        /* now see if things are very wrong out there */
        if (broken_driver) {
                printf("Fatal error: broken driver. It probably needs to
be con\verted.\n");
                printf("Search for 'broken_driver = 1' in the source for
more d\etails.\n");
                exit(EXIT_FAILURE);
        }

        if (do_forceshutdown)
                forceshutdown();



The call to setup_signals() does not reference any files in the statepath
directory.

memset() does not reference any files in the statepath directory

upsdrv_initups() does not reference any files in the statepath directory
... at least not for cyberpower.c nor apcsmart.c nor mge-utalk.c

Therefore, it looks to me like this chdir(dflt_statepath()) could happen
after the test for forceshutdown()

Q: Can the chdir(dflt_statepath()) be moved until after the test for
forceshutdown() ?


I did a quick search and did not even see any reason for this
chdir(dflt_statepath()) to be happening at the driver level. Presumably
someone put it there for a reason, but I was unable to find it.

Q: Does someone have an example of where files in the dflt_statepath()
directory are being accessed at the driver level?

The Fedora distributions contain scripts that are specific to nut.

Q: Who maintains the Fedora/RedHat scripts for nut support?

Q: What can I do to help get these issues resolved?


Miguel