February 14, 20215 yr HI, Does anyone knows why I have these lines in my log? There are no errors before or after: >> Feb 14 03:55:41 Tower kernel: mdcmd (206): spindown 5 Feb 14 04:40:01 Tower apcupsd[27942]: apcupsd exiting, signal 15 Feb 14 04:40:01 Tower apcupsd[27942]: apcupsd shutdown succeeded Feb 14 04:40:04 Tower apcupsd[14778]: apcupsd 3.14.14 (31 May 2016) slackware startup succeeded Feb 14 04:40:04 Tower apcupsd[14778]: NIS server startup succeeded Feb 14 05:41:50 Tower kernel: mdcmd (207): spindown 2 << Thank you
February 14, 20215 yr Author Found another instance of the log entries at exact same time one week ago. Must be some settings somewhere but what? >> Feb 7 04:40:01 Tower apcupsd[2165]: apcupsd exiting, signal 15 Feb 7 04:40:01 Tower apcupsd[2165]: apcupsd shutdown succeeded Feb 7 04:40:04 Tower apcupsd[27942]: apcupsd 3.14.14 (31 May 2016) slackware startup succeeded Feb 7 04:40:04 Tower apcupsd[27942]: NIS server startup succeeded <<
February 20, 20215 yr Also have a couple instinces of this in my log: Feb 14 04:40:01 Tower apcupsd[26901]: apcupsd exiting, signal 15 Feb 14 04:40:01 Tower apcupsd[26901]: apcupsd shutdown succeeded Feb 14 04:40:04 Tower apcupsd[6799]: apcupsd 3.14.14 (31 May 2016) slackware startup succeeded Feb 14 04:40:04 Tower apcupsd[6799]: NIS server startup succeeded Maybe this happened when the apcupsd plugin was updated? Did you find anything out?
March 28, 20215 yr Community Expert I'm going to bump this thread, as I'm seeing this in my logs (and at the same time) as well. Seems aligned with user.script.start.daily.sh It doesn't seem to cause any issue with apcupsd but just would be nice to confirm this from a routine task, and not indicative of any issue.
May 26, 20233 yr @BobNik @adminmat @ConnerVT @nraygun Hi guys. I was curious about this myself and here are some things that I found. As you can guess the apcupsd daemon controls the UPS communication. The number in brackets is the process ID of that daemon process. It seems that, on a weekly basis, the old process [524] is destroyed (exited) and a new process [13221] is created. Obviously your process numbers would be different from mine. This weekly restart process is controlled by "logrotate". You can find logrotate.conf in the "/etc" folder. Basically the logrotate config file is run and then all scripts within the logrotate.d folder are run. In the /etc/logrotate.d folder you'll see apcupsd which contains the following commands. The rc.d is a folder that contains "run commands" for daemons. More info here --> https://linux.die.net/man/8/logrotate and https://forums.unraid.net/topic/119894-resolved-problems-with-apcupsd-starting-at-regular-times-when-disabled/ The UPS Self Test is a test that the UPS performs on a regular basis and the apcupsd daemon simply posts the results to the log. It's interesting my settings show SELFTEST = NO and yet my UPS still does a regular Self Test. Maybe just a bug with apcupsd. See this for more info about the Self Test --> https://www.apc.com/ca/en/faqs/FA405317/ Note below in the screenshots that everything in my settings jives with the logs especially the power failure at 6:50:34 lasting for 2 seconds. Edited May 26, 20233 yr by TimTheSettler
May 26, 20233 yr Thanks @TimTheSettler! So it's basically a weekly restart of the apcupsd daemon and no cause for concern, right?
May 31, 20233 yr On 5/26/2023 at 4:57 PM, nraygun said: So it's basically a weekly restart of the apcupsd daemon and no cause for concern, right? That's how I understand it. The daemon is restarted so that a new log can be started.
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.