May 25, 20197 yr 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 Edited May 25, 20197 yr by KidCastro
May 25, 20197 yr Author 1 minute ago, Squid said: Any user scripts running hourly? How can I check this, I haven't played around with scripts before. I have run Unraid for a very long time so maybe I did something a long time ago. Edited May 25, 20197 yr by KidCastro
May 26, 20197 yr Author 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
May 26, 20197 yr Community Expert 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.
May 26, 20197 yr Author 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.
May 26, 20197 yr 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.
May 27, 20197 yr Author 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
May 27, 20197 yr 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.
May 28, 20197 yr Author 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. @John_M You are a legend 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 May 28, 20197 yr by KidCastro
May 28, 20197 yr 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.
Archived
This topic is now archived and is closed to further replies.