Project

General

Profile

Bug #7976

UPS service; chown on non existing files, when stopping UPS service in slave mode

Added by Roger Wilco over 5 years ago. Updated about 4 years ago.

Status:
Resolved
Priority:
Nice to have
Assignee:
Josh Paetzel
Category:
OS
Target version:
Seen in:
Severity:
New
Reason for Closing:
Reason for Blocked:
Needs QA:
Yes
Needs Doc:
Yes
Needs Merging:
Yes
Needs Automation:
No
Support Suite Ticket:
n/a
Hardware Configuration:
ChangeLog Required:
No

Description

Hi,

there is an issue with the NUT config files, when the UPS service is stopped in slave mode, which results in FreeNAS trying to change owner of non existing files.

How to reproduce:
1. Configure the UPS service as slave
2. Start the UPS service
3. Reboot the box, in case the service has ever been configured as master since the last reboot <--- This reboot mandatory to reproduce the issue
4. Stop the UPS service

This will result in the following log records:
Feb 11 21:12:14 freenas02 notifier: chown: /usr/local/etc/nut/ups.conf: No such file or directory
Feb 11 21:12:14 freenas02 notifier: chown: /usr/local/etc/nut/upsd.users: No such file or directory
Feb 11 21:12:14 freenas02 notifier: chown: /usr/local/etc/nut/upsd.conf: No such file or directory
Feb 11 21:12:14 freenas02 notifier: chmod: /usr/local/etc/nut/ups.conf: No such file or directory
Feb 11 21:12:14 freenas02 notifier: chmod: /usr/local/etc/nut/upsd.users: No such file or directory
Feb 11 21:12:14 freenas02 notifier: chmod: /usr/local/etc/nut/upsd.conf: No such file or directory
Feb 11 21:12:14 freenas02 notifier: nut not running? (check /var/db/nut/upsd.pid).
Feb 11 21:12:14 freenas02 notifier: Stopping nut_upsmon.
Feb 11 21:12:14 freenas02 upsmon[2146]: upsmon parent: read
Feb 11 21:12:14 freenas02 notifier: Waiting for PIDS: 2148.
Feb 11 21:12:14 freenas02 notifier: Stopping nut_upslog.
Feb 11 21:12:14 freenas02 notifier: Waiting for PIDS: 2143.
Feb 11 21:12:15 freenas02 notifier: Will not 'restart' nut because nut_enable is NO.
Feb 11 21:12:15 freenas02 notifier: Will not 'restart' nut_upsmon because nut_upsmon_enable is NO.
Feb 11 21:12:15 freenas02 notifier: Will not 'restart' nut_upslog because nut_upslog_enable is NO.

If the UPS service has ever been configured as master since the last reboot and then changed to slave, everything's fine, as the mentioned "master" files exist.
This might be another issue - why should config files of a non existing configuration be kept (no matter whether it is until the next reboot only, or forever)?

Associated revisions

Revision ea41133f (diff)
Added by Josh Paetzel over 5 years ago

Be a bit smarter about setting permissions. Ticket: #7976 Only set permissions for things that are generated. Nuke files that aren't generated. (master and slave mode generate different files) Previous to this commit we tried to blindly set permissions on files regardless of whether they existed or not. If the UPS mode was changed we could leave dangling files behind from previous runs of the config file generator, fix that as well.

Revision a989fbc5 (diff)
Added by Josh Paetzel over 5 years ago

Be a bit smarter about setting permissions. Ticket: #7976 Only set permissions for things that are generated. Nuke files that aren't generated. (master and slave mode generate different files) Previous to this commit we tried to blindly set permissions on files regardless of whether they existed or not. If the UPS mode was changed we could leave dangling files behind from previous runs of the config file generator, fix that as well. (cherry picked from commit ea41133fccc2ddec862e3b8a74b069af21dd4731)

Revision 84590bf5 (diff)
Added by Josh Paetzel over 5 years ago

Be a bit smarter about setting permissions. Ticket: #7976 Only set permissions for things that are generated. Nuke files that aren't generated. (master and slave mode generate different files) Previous to this commit we tried to blindly set permissions on files regardless of whether they existed or not. If the UPS mode was changed we could leave dangling files behind from previous runs of the config file generator, fix that as well. (cherry picked from commit ea41133fccc2ddec862e3b8a74b069af21dd4731)

History

#1 Updated by Jordan Hubbard over 5 years ago

  • Category set to 129
  • Assignee set to Josh Paetzel

Hmmm. Benign or indicative of a greater problem? Not sure, over to Josh to triage.

#2 Updated by Josh Paetzel over 5 years ago

  • Status changed from Unscreened to Screened
  • Target version set to Unspecified

Benign, but easily fixable.

Slightly harder to fix but still benign is the keeping of files from a master config.

#3 Updated by Roger Wilco over 5 years ago

Josh Paetzel wrote:

Benign, but easily fixable.

Slightly harder to fix but still benign is the keeping of files from a master config.

Hi,
the second might be a design question - on one hand why should FreeNAS keep files of a non existing configuration, but on the other hand should FreeNAS really delete possibly hand-crafted files? What if the user just wants to try out something, switches from master to slave, and boom all master configuration is gone...
I don't know what's right, maybe it's just fine to keep them...

#4 Updated by Josh Paetzel over 5 years ago

  • Status changed from Screened to Ready For Release
  • Seen in changed from to

#5 Updated by Jordan Hubbard over 5 years ago

  • Status changed from Ready For Release to Resolved

#6 Avatar?id=14398&size=24x24 Updated by Kris Moore about 4 years ago

  • Target version changed from Unspecified to N/A

Also available in: Atom PDF