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
