UPS in continuous shutdown loop

[technoholic]

Got myself into trouble when configuring the UPS service. Not knowing what driver would be correct for my Belkin unit, the first on the list of Belkin drivers was selected. Now as soon as the UPS daemon is started, the system immediatly shuts down with a low battery condition. this happens even with the UPS communication cable disconnectd.

I figured booting to the shell and renaming the upsmon.conf file would bypass the problem and get things back up. Problem is I cannot find upsmon.conf. I have looked in /ect/local/nut/ and /usr/local/etc/nut but the only thing in those locations are upsmon.conf.sample files. Now I am dead in the water.

Any help appreciated. How can I stop the UPS service from starting at boot?

I am running on 8.3.0

 

[Milhouse]

Presumably the UPS is being show as on battery power, or does the NAS think it is on mains power? If it's the latter, it's most likely ticket #1155 that is causing your shutdown (I realise the driver is messed up and giving bogus information, but the NAS shouldn't be shutting down when on mains power even if the battery is low). I posted a suggested fix, but no follow up.

As to how you stop the immediate shutdown in your case, I would suggest updating the database to disable UPS:

Code:

sqlite3 /data/freenas-v1.db "update services_services set srv_enable=0 where srv_service='ups'"

and if necessary, rebooting. Then find a working UPS driver before re-enabling...

 

[technoholic]

Presumably the UPS is being show as on battery power, or does the NAS think it is on mains power? If it's the latter, it's most likely ticket #1155 that is causing your shutdown (I realise the driver is messed up and giving bogus information, but the NAS shouldn't be shutting down when on mains power even if the battery is low). I posted a suggested fix, but no follow up.

As to how you stop the immediate shutdown in your case, I would suggest updating the database to disable UPS:

Code:

sqlite3 /data/freenas-v1.db "update services_services set srv_enable=0 where srv_service='ups'"

and if necessary, rebooting. Then find a working UPS driver before re-enabling...

Thanks for the reply. I looked at your bug report and must say it rang familiar from experience with another OS in a previous lifetime but that's another story. The problem here is that shutdown executes even when there is no UPS connected to the machine. The only option is to escape to shell from the FreeNAS splash screen and that shell only provides a limited command set to work with.

From what you are saying, it looks like the UPS configuration is contained in the database. That would explain why there apparently is no upsmon.conf file where one would expect to find it. Is that a correct assumption?

 

[Milhouse]

The problem here is that shutdown executes even when there is no UPS connected to the machine.

Yes I get that, that's why I said the driver is messed up and giving bogus information - it would be interesting to know if the FreeNAS thinks it is on battery or mains power even when no UPS is connected. If it's the latter, on mains power, then ticket 1155 is precisely why your machine is shutting down because of flaws in the notification script (without those flaws, even with a messed up driver, the NAS wouldn't keep shutting down while the NAS believes [rightly or wrongly] that it is on mains power).

Is that a correct assumption?

Yes.

 

[technoholic]

Yes I get that, that's why I said the driver is messed up and giving bogus information - it would be interesting to know if the FreeNAS thinks it is on battery or mains power even when no UPS is connected. If it's the latter, on mains power, then ticket 1155 is precisely why your machine is shutting down because of flaws in the notification script (without those flaws, even with a messed up driver, the NAS wouldn't keep shutting down while the NAS believes [rightly or wrongly] that it is on mains power).



Yes.

So it seems then that the road to recovery is to format the USB stick and reinstall FreeNAS. I am not aware of a way to replace the database under the current circumstances. Fortunatly I have a DB backup from just before starting UPS configuration.

Thanks again!

 

[Milhouse]

So it seems then that the road to recovery is to format the USB stick and reinstall FreeNAS. I am not aware of a way to replace the database under the current circumstances. Fortunatly I have a DB backup from just before starting UPS configuration.

Thanks again!

1. Boot into single user mode (4 on boot menu)
2. Mount /data partition

Code:

mount -t ufs /dev/ufs/FreeNASs4 /data

3. Disable UPS

Code:

sqlite3 /data/freenas-v1.db "update services_services set srv_enable=0 where srv_service='ups'"

4. Reboot

 

[technoholic]

Tried that but for some reason, boot to single user mode just would not complete. What I wound up doing was:

Boot to installation CD
Install (not upgrade)
Boot and restore DB from backup
2 more boots (system controlled)
System is back, all good with no data loss :D

It was a relatively painless recovery. I am not a seasoned user of FreeNAS and sure learned some stuff today thanks to you.
Live long and prosper!

 

[technoholic]

it would be interesting to know if the FreeNAS thinks it is on battery or mains power even when no UPS is connected.

Now that I think of it, the answer to that might be; three emails were generated everytime the system attempted to boot up:

ON BATT
LOW BATT
SHUTDOWN

the driver in question was blazer_usb and the problem occured even with the UPS completely out of the loop.

I have created Ticket 1898.