2 issues! Repeat error in log, please help and cpu usage


Recommended Posts

Hi guys

 

I've had this error for over a year, constantly in my logbook... can someone please assist with working out why these keep populating my log.

May 25 20:18:01 HORIZONLAB crond[1894]: failed parsing crontab for user root: /usr/bin/run-parts /etc/cron.hourly 1> /dev/null
May 25 20:18:01 HORIZONLAB crond[1894]: failed parsing crontab for user root: /usr/bin/run-parts /etc/cron.daily 1> /dev/null
May 25 20:18:01 HORIZONLAB crond[1894]: failed parsing crontab for user root: /usr/bin/run-parts /etc/cron.weekly 1> /dev/null
May 25 20:18:01 HORIZONLAB crond[1894]: failed parsing crontab for user root: /usr/bin/run-parts /etc/cron.monthly 1> /dev/null
May 25 20:33:01 HORIZONLAB crond[1894]: failed parsing crontab for user root: /usr/bin/run-parts /etc/cron.hourly 1> /dev/null
May 25 20:33:01 HORIZONLAB crond[1894]: failed parsing crontab for user root: /usr/bin/run-parts /etc/cron.daily 1> /dev/null
May 25 20:33:01 HORIZONLAB crond[1894]: failed parsing crontab for user root: /usr/bin/run-parts /etc/cron.weekly 1> /dev/null
May 25 20:33:01 HORIZONLAB crond[1894]: failed parsing crontab for user root: /usr/bin/run-parts /etc/cron.monthly 1> /dev/null
May 25 20:48:02 HORIZONLAB crond[1894]: failed parsing crontab for user root: /usr/bin/run-parts /etc/cron.hourly 1> /dev/null
May 25 20:48:02 HORIZONLAB crond[1894]: failed parsing crontab for user root: /usr/bin/run-parts /etc/cron.daily 1> /dev/null
May 25 20:48:02 HORIZONLAB crond[1894]: failed parsing crontab for user root: /usr/bin/run-parts /etc/cron.weekly 1> /dev/null
May 25 20:48:02 HORIZONLAB crond[1894]: failed parsing crontab for user root: /usr/bin/run-parts /etc/cron.monthly 1> /dev/null
May 25 21:03:02 HORIZONLAB crond[1894]: failed parsing crontab for user root: /usr/bin/run-parts /etc/cron.hourly 1> 

Also I recently upgraded my motherboard, cpu and ram to i5 8400, Asus B365M-A and 16GB Corsair DDR. My CPU clock is constantly showing high clock speed even though my load doesn't warrant it.

Command: watch -n 1.0  "cat /proc/cpuinfo | grep -i mhz"

Every 1.0s: cat /proc/cpuinfo | grep -i mhz HORIZONLAB: Sat May 25 22:01:08 2019

cpu MHz         : 3838.821
cpu MHz         : 3830.289
cpu MHz         : 3893.794
cpu MHz         : 3869.166
cpu MHz         : 3886.809
cpu MHz         : 3888.813

859559586_ScreenShot2019-05-25at10_03_53pm.png.08b98279378c5659ccbc472d97032902.png

Edited by KidCastro
Link to comment
7 hours ago, Squid said:

What's the output of

 


crontab -l

 

root@HORIZONLAB:~# crontab -l
# If you don't want the output of a cron job mailed to you, you have to direct
# any output to /dev/null.  We'll do this here since these jobs should run
# properly on a newly installed system.  If a script fails, run-parts will
# mail a notice to root.
#
# Run the hourly, daily, weekly, and monthly cron jobs.
# Jobs that need different timing may be entered into the crontab as before,
# but most really don't need greater granularity than this.  If the exact
# times of the hourly, daily, weekly, and monthly cron jobs do not suit your
# needs, feel free to adjust them.
#
# Run hourly cron jobs at 47 minutes after the hour:
 * * * * /usr/bin/run-parts /etc/cron.hourly 1> /dev/null
#
# Run daily cron jobs at 4:40 every day:
  * * * /usr/bin/run-parts /etc/cron.daily 1> /dev/null
#
# Run weekly cron jobs at 4:30 on the first day of the week:
  * *  /usr/bin/run-parts /etc/cron.weekly 1> /dev/null
#
# Run monthly cron jobs at 4:20 on the first day of the month:
   * * /usr/bin/run-parts /etc/cron.monthly 1> /dev/null

 

Link to comment

That is definitely wrong.  My system shows

root@DJW-UNRAID-VM2:~# crontab -l
# If you don't want the output of a cron job mailed to you, you have to direct
# any output to /dev/null.  We'll do this here since these jobs should run
# properly on a newly installed system.  If a script fails, run-parts will
# mail a notice to root.
#
# Run the hourly, daily, weekly, and monthly cron jobs.
# Jobs that need different timing may be entered into the crontab as before,
# but most really don't need greater granularity than this.  If the exact
# times of the hourly, daily, weekly, and monthly cron jobs do not suit your
# needs, feel free to adjust them.
#
# Run hourly cron jobs at 47 minutes after the hour:
47 * * * * /usr/bin/run-parts /etc/cron.hourly 1> /dev/null
#
# Run daily cron jobs at 4:40 every day:
40 4 * * * /usr/bin/run-parts /etc/cron.daily 1> /dev/null
#
# Run weekly cron jobs at 4:30 on the first day of the week:
30 4 * * 0 /usr/bin/run-parts /etc/cron.weekly 1> /dev/null
#
# Run monthly cron jobs at 4:20 on the first day of the month:
20 4 1 * * /usr/bin/run-parts /etc/cron.monthly 1> /dev/null

As you can see your entries are missing the fields that specify the times which explains your error messages.  I cannot remember how you can reset these via the GUI. :(

Link to comment
40 minutes ago, itimpi said:

That is definitely wrong.  My system shows


root@DJW-UNRAID-VM2:~# crontab -l
# If you don't want the output of a cron job mailed to you, you have to direct
# any output to /dev/null.  We'll do this here since these jobs should run
# properly on a newly installed system.  If a script fails, run-parts will
# mail a notice to root.
#
# Run the hourly, daily, weekly, and monthly cron jobs.
# Jobs that need different timing may be entered into the crontab as before,
# but most really don't need greater granularity than this.  If the exact
# times of the hourly, daily, weekly, and monthly cron jobs do not suit your
# needs, feel free to adjust them.
#
# Run hourly cron jobs at 47 minutes after the hour:
47 * * * * /usr/bin/run-parts /etc/cron.hourly 1> /dev/null
#
# Run daily cron jobs at 4:40 every day:
40 4 * * * /usr/bin/run-parts /etc/cron.daily 1> /dev/null
#
# Run weekly cron jobs at 4:30 on the first day of the week:
30 4 * * 0 /usr/bin/run-parts /etc/cron.weekly 1> /dev/null
#
# Run monthly cron jobs at 4:20 on the first day of the month:
20 4 1 * * /usr/bin/run-parts /etc/cron.monthly 1> /dev/null

As you can see your entries are missing the fields that specify the times which explains your error messages.  I cannot remember how you can reset these via the GUI. :(

:( Thanks for figuring that out, hope someone has an idea, I need to fix this... the errors are happening every 15mins.

Link to comment

Do you have the Dynamix Schedules plugin installed? If you do you can reset the schedules by going to Settings -> Scheduler and scrolling down to the Fixed Schedules section. Have you tried rebooting? That might fix it as the crontabs are, I believe, re-created when you boot. You might want to run a disk check on your USB boot device on a separate PC (shut down Unraid before unplugging it) in case it has become corrupt.

Link to comment
17 hours ago, John_M said:

Do you have the Dynamix Schedules plugin installed? If you do you can reset the schedules by going to Settings -> Scheduler and scrolling down to the Fixed Schedules section. Have you tried rebooting? That might fix it as the crontabs are, I believe, re-created when you boot. You might want to run a disk check on your USB boot device on a separate PC (shut down Unraid before unplugging it) in case it has become corrupt.

Thanks @John_M I reset the Fixed Schedules and my output of crontab -l is below. Is this correct now? I'm not seeing these failed parsing crontab for user root logs as frequent.

root@HORIZONLAB:~# crontab -l
# If you don't want the output of a cron job mailed to you, you have to direct
# any output to /dev/null.  We'll do this here since these jobs should run
# properly on a newly installed system.  If a script fails, run-parts will
# mail a notice to root.
#
# Run the hourly, daily, weekly, and monthly cron jobs.
# Jobs that need different timing may be entered into the crontab as before,
# but most really don't need greater granularity than this.  If the exact
# times of the hourly, daily, weekly, and monthly cron jobs do not suit your
# needs, feel free to adjust them.
#
# Run hourly cron jobs at 47 minutes after the hour:
47 * * * * /usr/bin/run-parts /etc/cron.hourly 1> /dev/null
#
# Run daily cron jobs at 4:40 every day:
40 4 * * * /usr/bin/run-parts /etc/cron.daily 1> /dev/null
#
# Run weekly cron jobs at 4:30 on the first day of the week:
30 4 * * 0 /usr/bin/run-parts /etc/cron.weekly 1> /dev/null
#
# Run monthly cron jobs at 4:20 on the first day of the month:
20 4 1 * * /usr/bin/run-parts /etc/cron.monthly 1> /dev/null

The only issue I have left is my CPU clock speed is always high even though load is low.

Is the command watch -n 1.0 "cat /proc/cpuinfo | grep -i mhz" accurate?

Every 1.0s: cat /proc/cpuinfo | grep -i mhz HORIZONLAB: Mon May 27 15:06:03 2019

cpu MHz         : 3850.181
cpu MHz         : 3806.042
cpu MHz         : 3893.782
cpu MHz         : 3887.109
cpu MHz         : 3454.613
cpu MHz         : 3889.451

 

Link to comment

Yes, your crontab looks good now.

 

I can't comment on your CPU usage because I don't have enough information. Try monitoring your running processes with htop to see if there's something keeping your CPU busy. Some Docker containers, such as Plex, do a lot of housekeeping in the background. The command you give should be accurate for assessing clock speeds, provided you're running it from an Unraid command prompt. It won't be accurate if you run it from within a VM, for example. If you have the Tips and Tweaks plugin installed you can choose a different CPU scaling governor, such as "Power Save" or "On Demand" if it's available. Yours might be set to Performance, perhaps.

 

1046293548_ScreenShot2019-05-27at20_02_09.png.635292c2050c26f5525c3f4192e13eb5.png

Link to comment
16 hours ago, John_M said:

Yes, your crontab looks good now.

 

I can't comment on your CPU usage because I don't have enough information. Try monitoring your running processes with htop to see if there's something keeping your CPU busy. Some Docker containers, such as Plex, do a lot of housekeeping in the background. The command you give should be accurate for assessing clock speeds, provided you're running it from an Unraid command prompt. It won't be accurate if you run it from within a VM, for example. If you have the Tips and Tweaks plugin installed you can choose a different CPU scaling governor, such as "Power Save" or "On Demand" if it's available. Yours might be set to Performance, perhaps.

 

1046293548_ScreenShot2019-05-27at20_02_09.png.635292c2050c26f5525c3f4192e13eb5.png

@John_M You are a legend :D I installed Tips and Tweaks and as you said it was set to...

 

CPU Frequency Scaling

Driver: Intel Pstate

Governor: Performance

 

I set it to Governor: Power Save and now the CPU is scaling down to 800mhz when I'm not doing anything.

Every 1.0s: cat /proc/cpuinfo | grep -i mhz HORIZONLAB: Tue May 28 21:48:08 2019

cpu MHz         : 800.107
cpu MHz         : 800.228
cpu MHz         : 800.026
cpu MHz         : 800.041
cpu MHz         : 800.067
cpu MHz         : 800.000

I just want to know why this was set to performance by default and also will this affect performance at all?

Edited by KidCastro
Link to comment

Maybe the performance option is a safe default or maybe your CPU's capabilities weren't correctly detected. Perhaps there's a BIOS setting that chooses a performance profile. If the clock speeds ramp up again as you load the CPU then it's working fine. As to whether it affects performance, I suppose the purist would say that for the few milliseconds it takes to ramp up the clocks from idle you're not getting the maximum performance but I don't think you'll ever notice. FWIW the screenshot is from my Ivy Bridge Celeron powered HP Microserver Gen 8 and when the governor is set to "Power Save" it idles at the lowest clock speed but ramps up when needed. My other Unraid servers have AMD processors and offer more choices for the CPU governor with "Cool'n'Quiet" enabled in the BIOS. On these I have "On Demand" selected in the menu and that works as expected too. There's more information here.

  • Like 1
Link to comment

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.