LateNight

Members
 View Profile  See their activity

  • Posts

    103

  • Joined

  • Last visited

 Content Type 

Posts posted by LateNight

    [Plugin] Parity Check Tuning

    in Plugin Support

    Posted

    9 hours ago, itimpi said:


    Thanks for the information.   Glad to hear that going through the settings screen seems to have fixed the issue.

     

    There was an internal change to the way that the configuration information was stored.   I can see that the .cfg file you posted is still in the old format.  I thought I had put in place the code that migrated old format to new one but it looks like I missed an entry that affects the generation of the cron entries.  Using the information you have provided I can fix this but hopefully it is a short term issue.

     

    Going in and saving again, without making changes, fixed the issue. No log entries overnight. Thank you.

    [Plugin] Parity Check Tuning

    in Plugin Support

    Posted

    Quote

    It is regenerated any time you make a change in the plugin’s settings to be appropriate for the current settings so it might be worth doing that to see if it magically ‘cures’ the problem.

     

    Just went into settings again and saved (no changes). New parity.check.tuning.cron: 

    # Generated schedules for parity.check.tuning
0 23 * * * /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "resume" &> /dev/null
0 7 * * * /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "pause" &> /dev/null
*/7 * * * * /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null

     

    I'm guessing that fixed the issue - will check in the morning.

    [Plugin] Parity Check Tuning

    in Plugin Support

    Posted

    Log: 

    Feb 8 23:04:02 DeathStar crond[2219]: failed parsing crontab for user root: /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "resume" &> /dev/null
Feb 8 23:04:02 DeathStar crond[2219]: failed parsing crontab for user root: /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "pause" &> /dev/null
Feb 8 23:19:01 DeathStar crond[2219]: failed parsing crontab for user root: /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "resume" &> /dev/null
Feb 8 23:19:01 DeathStar crond[2219]: failed parsing crontab for user root: /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "pause" &> /dev/null
Feb 8 23:34:01 DeathStar crond[2219]: failed parsing crontab for user root: /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "resume" &> /dev/null
Feb 8 23:34:01 DeathStar crond[2219]: failed parsing crontab for user root: /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "pause" &> /dev/null
Feb 8 23:48:02 DeathStar crond[2219]: failed parsing crontab for user root: /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "resume" &> /dev/null
Feb 8 23:48:02 DeathStar crond[2219]: failed parsing crontab for user root: /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "pause" &> /dev/null
Feb 9 00:03:02 DeathStar crond[2219]: failed parsing crontab for user root: /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "resume" &> /dev/null

     

    parity.check.tuning.cron 

    # Generated schedules for parity.check.tuning
 /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "resume" &> /dev/null
 /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "pause" &> /dev/null
*/7 * * * * /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null

     

    parity.tuning.cfg 

    parityTuningIncrements="yes"
parityTuningFrequency="daily"
parityTuningResumeCustom=""
parityTuningResumeHour="23"
parityTuningResumeMinute="0"
parityTuningPauseCustom=""
parityTuningPauseHour="7"
parityTuningPauseMinute="0"
parityTuningUnscheduled="yes"
parityTuningRecon="no"
parityTuningClear="no"
parityTuningNotify="no"
parityTuningHeat="yes"
parityTuningHeatHigh="2"
parityTuningHeatLow="10"
parityTuningHeatNotify="yes"
parityTuningDebug="no"
parityTuningHeatShutdown="yes"
parityTuningHeatCritical="1"

     

    parity-checks.log parity.check.tuning.progress.save

    Intel Socket 1151 Motherboards with IPMI AND Support for iGPU

    in Motherboards and CPUs

    Posted

    I've had Turbo disabled but decided to re-enable it again last night. Server crashed overnight. I wasn't running anything that should stress the server. 

    ¯\_(ツ)_/¯

     

    image.png.cbff4832789ecc22bf5ed1548536940e.png

    Quote

    <13>Oct 29 20:17:58 DeathStar tips.and.tweaks: Tweaks Applied
    <4>Oct 29 20:46:26 DeathStar kernel: mdcmd (237): spindown 4
    <4>Oct 29 20:46:36 DeathStar kernel: mdcmd (238): spindown 0
    <4>Oct 29 20:46:37 DeathStar kernel: mdcmd (239): spindown 2
    <4>Oct 29 20:46:38 DeathStar kernel: mdcmd (240): spindown 3
    <4>Oct 29 20:46:38 DeathStar kernel: mdcmd (241): spindown 5    
    <4>Oct 29 20:46:39 DeathStar kernel: mdcmd (242): spindown 6
    <4>Oct 29 20:46:40 DeathStar kernel: mdcmd (243): spindown 8
    <4>Oct 29 21:01:01 DeathStar kernel: mdcmd (244): spindown 1    
    <4>Oct 29 21:36:33 DeathStar kernel: mdcmd (245): spindown 7
    <4>Oct 29 22:53:26 DeathStar kernel: mdcmd (246): spindown 1    
    <4>Oct 29 23:28:42 DeathStar kernel: mdcmd (247): spindown 7
    <4>Oct 29 23:56:41 DeathStar kernel: mdcmd (248): spindown 6
    <6>Oct 30 00:10:36 DeathStar kernel: veth983241a: renamed from eth0
    <6>Oct 30 00:10:36 DeathStar kernel: docker0: port 2(vethca62111) entered disabled state
    <6>Oct 30 00:10:36 DeathStar kernel: docker0: port 2(vethca62111) entered disabled state    
    <6>Oct 30 00:10:36 DeathStar kernel: device vethca62111 left promiscuous mode
    <6>Oct 30 00:10:36 DeathStar kernel: docker0: port 2(vethca62111) entered disabled state
    <6>Oct 30 00:10:37 DeathStar kernel: docker0: port 2(veth5dc5130) entered blocking state
    <6>Oct 30 00:10:37 DeathStar kernel: docker0: port 2(veth5dc5130) entered disabled state
    <6>Oct 30 00:10:37 DeathStar kernel: device veth5dc5130 entered promiscuous mode
    <6>Oct 30 00:10:37 DeathStar kernel: IPv6: ADDRCONF(NETDEV_UP): veth5dc5130: link is not ready
    <6>Oct 30 00:10:37 DeathStar kernel: docker0: port 2(veth5dc5130) entered blocking state
    <6>Oct 30 00:10:37 DeathStar kernel: docker0: port 2(veth5dc5130) entered forwarding state
    <6>Oct 30 00:10:37 DeathStar kernel: docker0: port 2(veth5dc5130) entered disabled state
    <6>Oct 30 00:10:37 DeathStar kernel: eth0: renamed from vethba80b6a
    <6>Oct 30 00:10:37 DeathStar kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth5dc5130: link becomes ready    
    <6>Oct 30 00:10:37 DeathStar kernel: docker0: port 2(veth5dc5130) entered blocking state
    <6>Oct 30 00:10:37 DeathStar kernel: docker0: port 2(veth5dc5130) entered forwarding state
    <13>Oct 30 01:00:01 DeathStar Plugin Auto Update: Checking for available plugin updates
    <13>Oct 30 01:00:03 DeathStar Plugin Auto Update: Community Applications Plugin Auto Update finished
    <77>Oct 30 04:00:49 DeathStar crond[2213]: exit status 1 from user root /usr/local/sbin/mover &> /dev/null    
    <4>Oct 30 04:35:21 DeathStar kernel: mdcmd (249): spindown 0

     

    [Plugin] Parity Check Tuning

    in Plugin Support

    Posted

    I have the following debug messages every five minutes in my log:

    Quote

    parity.check.tuning.php: DEBUG: -----------MONITOR start------
    parity.check.tuning.php: DEBUG: No drives appear to have reached shutdown threshold   
    parity.check.tuning.php: DEBUG: No array operation currently in progress
    DeathStar parity.check.tuning.php: DEBUG: -----------MONITOR end-------

    I did verify that I have logging disabled.

    image.thumb.png.7dfa97743b92c6f24e634c5e1fd4dea4.png

    This started after the most recent update - 2020.10.23

    Intel Socket 1151 Motherboards with IPMI AND Support for iGPU

    in Motherboards and CPUs

    Posted · Edited by LateNight

    Thank you @Hoopster for this deal/thread. I upgraded my almost 9 year old server.

     

    I'm running into an odd issue and trying to determine if it's hardware or software. My system runs fine until I start a parity check. During the parity check unRaid freezes but I am still able to reach the IPMI interface.  I'm using BMC Firmware 1.80.00 and BIOS Firmware L2.21A. From my IPMI event log it shows CPU_CATERR. 

     3    | 07/04/2020, 08:34:35 | CPU_CATERR       | Processor                          | State Asserted - Asserted

    I ran a syslog server but I don't see anything related. 

    <30>Jul  4 02:46:03 DeathStar ool www[17368]: /usr/local/emhttp/plugins/dynamix/scripts/rsyslog_config    192.168.1.5    04/07 02:46:03.013    
<46>Jul  4 02:46:06 DeathStar rsyslogd: [origin software="rsyslogd" swVersion="8.1908.0" x-pid="17979" x-info="https://www.rsyslog.com"] start    192.168.1.5    04/07 02:46:05.473    
<4>Jul  4 02:46:32 DeathStar kernel: mdcmd (88): spindown 3    192.168.1.5    04/07 02:46:31.123    
<4>Jul  4 02:46:32 DeathStar kernel: mdcmd (89): spindown 6    192.168.1.5    04/07 02:46:32.001    
<4>Jul  4 02:46:34 DeathStar kernel: mdcmd (90): spindown 4    192.168.1.5    04/07 02:46:33.832    
<4>Jul  4 02:46:35 DeathStar kernel: mdcmd (91): spindown 5    192.168.1.5    04/07 02:46:34.483    
<4>Jul  4 02:46:45 DeathStar kernel: mdcmd (92): check     192.168.1.5    04/07 02:46:44.087    
<4>Jul  4 02:46:45 DeathStar kernel: md: recovery thread: check P ...    192.168.1.5    04/07 02:46:44.087    
<13>Jul  4 03:00:01 DeathStar Recycle Bin: Scheduled: Files older than 7 days have been removed    192.168.1.5    04/07 03:00:00.645    
<77>Jul  4 03:40:21 DeathStar crond[2295]: exit status 1 from user root /usr/local/sbin/mover &> /dev/null    192.168.1.5    04/07 03:40:20.584    

    I also downloaded the MCA Log (attached). It looks like the CPU may be defective, but I've never seen anything like it. 

    CPU1 Do not Present!!
Get CPU0 MCA Error Source Log failed: CC = 0x81
Get CPU core number failed: CC = 0x81. Default catch 28 cores.

    Diagnostics also attached, run just after rebooting.

     

    Any help is appreciated, and can move this to its own topic if needed.

    MCALog.txt deathstar-diagnostics-20200704-1144.zip

    WebGUI not accessible (solved)

    in General Support

    Posted · Edited by LateNight

    Went to watch something on Plex but it wouldn't connect to my Plex Server which is a docker on my Unraid machine. Tried browsing to tower/dashboard and it fails to load in any browser or device. Tried direct ip and still a no go. I can browse via file explorer on Win10 and can ssh in. Tried a reboot but that didn't fix the problem. Attached is the diagnostic zip. Thank you for any help.

    . deathstar-diagnostics-20180511-2243.zip