Apcupsd exiting, signal 15

[BobNik]

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

[BobNik]

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

<<

[adminmat]

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?

[adminmat]

I JUST noticed that this was logged at the same time mine was !

[ConnerVT]

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.

 

 

[nraygun]

@ConnerVTDid you ever find anything out about this log entry?

[TimTheSettler]

@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 by TimTheSettler

[nraygun]

Thanks @TimTheSettler!

So it's basically a weekly restart of the apcupsd daemon and no cause for concern, right?

[TimTheSettler]

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.