I'm a pretty competent Linux user but this is baffling me. My RN104 turns itself on one a month around the 10th of each month (if the NAS is turned off). What is triggering this? I cannot find a setting on the web UI.
I don't have Wake-on-LAN on, nor do I have any Wake-on-LAN demons on the network... so it's not that.
It has been doing this for over a year, and currently it's running 6.10.0 HotFix 2.
Model: RN10400|ReadyNAS 100 Series 4- Bay (Diskless)
Hi @booboo59, to get more info about a potential power issue I would do the following:
Case1: If the nas is currently hooked up to a ups, around the evening of the 9th of a month I would disconnect it from the ups and directly hook it up to a power outlet in the wall. Then see what happens on the 10th.
Case2: If the nas is currently NOT hooked up to a ups, try one. There are cheap models from APC, which are very reliable. I'm using several Back-UPS ES 700 and have virtually no power issues at all.
There is a power schedule in the UI, though you'd have needed to create power on events there, since it is isn't enabled by default.
@Retired_Member is thinking it is power related. If the power fails on the circuit, the NAS will boot when it is restored. So that is a possibility (though it does seem unlikely that this would happen so regularly).
The NAS is connected to a UPS but doesn't have the UPS USB/Serial connected, nor the UPS settings enabled. The UPS is serving another computer that is on 100% of the time and it doesn't reboot on the 10th, so I don't currently suspect the UPS having a "hiccup" on that date.
I think I will move the NAS off the UPS and see if that fixes it though.
Could it be the "rn-update.timer" ? Running #systemctl status rn-update.timer gives me this, which seems to coincide around the last boot time (see my previous message). It's labeled as vendor preset enabled, which would seem to me to be a documented feature and everyone's NAS should be autobooting monthly.
root@nas-E5-22-96:~# systemctl status rn-update.timer
● rn-update.timer - Timer for ReadyNAS Update Service Loaded: loaded (/lib/systemd/system/rn-update.timer; enabled; vendor preset: enabled) Active: active (waiting) since Sat 2019-05-11 21:21:29 CDT; 15h ago
May 11 21:21:29 nas-E5-22-96 systemd[1]: Started Timer for ReadyNAS Update Service.
Hi @booboo59, you wrote "The UPS is serving another computer that is on 100% of the time..."
Would it be correct to assume, that your pc is communicating to that ups and that you have a management software installed on the pc to control/manage that communication?
If yes, I would not bet the ranch, but would speculate into the direction that management software on your pc is doing something to the ups on a regular base (once a month around the 10th?) and your nas is suffering from that.
Disregarding the outcome of your further research I would definitely change your setup as follows: Let the nas communicate to the ups and stop the pc from doing that. If necessary you can configure the ups temporarily using the pc, but ongoing communication should be between ups and nas.
It's labeled as vendor preset enabled, which would seem to me to be a documented feature and everyone's NAS should be autobooting monthly.
My guess is that the timer won't actually start up the NAS. FWIW, my own RN102 and RN104 are normally powered down (with WoL enabled, as I do try things on them now and again). One is on a UPS, the other is not. Neither booted up spontaneously recently. Though I did see spontaneous boots of these NAS occasionally some time back. What firmware are you running?
Personally, I wouldn't change the PC monitoring (it seems like a very long shot to me anyway). Instead I'd move the RN104 power connection to a wall plug, and see if the behavior changes. The more basic question is whether the spontaneous boot is related to the UPS or not.
StephenB, I'm currently running 6.10.0. However the NAS has been doing this since 2018, and I've maintained up to date on firmware. So older versions have done it. What I haven't done is reset to factory, to see if some setting was inavertately set by a firware upgrade. There's no power schedule set on the GUI....
Because the NAS is rarely on, so the chances of the NAS being awake and take active control of the UPS is low. At any rate, this is all assuming that for some reason the UPS is causing this precisely once a month, which seems unlikely as the UPS doesn't have a realtime clock (to my knowledge).
Okay, @booboo59 , if you can afford and have the patience please do nothing else than I already suggested in message 2 of x: Directly connect the power cable to the wall and see what happens around the 10th of next month. If the behaviour is as observed in the past, you will finally know, that it is not related to your ups.
Of course you can try other approaches as available and hopefully find the root cause of your issue earlier.
Because the NAS is rarely on, so the chances of the NAS being awake and take active control of the UPS is low.
The NAS doesn't take "active control" of the UPS. The purpose of it's monitoring is simply for the NAS to shut down before the UPS battery runs down. That helps prevent data loss.
I get that you can make a case that the PC should be monitoring (and perhaps controlling) the UPS instead. But since you've chosen not to do that, then it makes sense to monitor it from the NAS.
Why did you connect it to the UPS power in the in the first place? The same argument applies.
In any event, monitoring is a free feature that offers some protection against data loss. I'll grant you that the value of monitoring is less if the NAS isn't on much. But if the NAS is powering itself up for some reason, it would be nice to ensure that it would power down gracefully if you were to lose power.
Also, if you were monitoring and left the NAS on around the 10th next month, you could look for UPS events in the log. That might give some clues as to what is going on.
Well it's up to you of course. But if my backup NAS was turning on when I didn't expect it, then there's a good chance I wouldn't notice it right away (perhaps days). In that scenario, I'd certainly want to ensure clean shutdowns. And it is possible that the monitoring would give clues on what's going on.
We've spent far more time talking about it than it would have taken you to connect the cable.
