mgworek Posted February 25, 2011 Share Posted February 25, 2011 I am on 5.0-Beta4 I get this error every hour. It has been happening for awhile. Tried searching the forums but did not find any answers. System seems to be running fine, just want to know what this is and if I should be worried or if their is a way to fix it. Thanks! Feb 25 13:37:01 Tower crond[1150]: ignoring /var/spool/cron/crontabs/root- (non-existent user) Feb 25 14:37:01 Tower crond[1150]: ignoring /var/spool/cron/crontabs/root- (non-existent user) Quote Link to comment
Joe L. Posted February 25, 2011 Share Posted February 25, 2011 I am on 5.0-Beta4 I get this error every hour. It has been happening for awhile. Tried searching the forums but did not find any answers. System seems to be running fine, just want to know what this is and if I should be worried or if their is a way to fix it. Thanks! Feb 25 13:37:01 Tower crond[1150]: ignoring /var/spool/cron/crontabs/root- (non-existent user) Feb 25 14:37:01 Tower crond[1150]: ignoring /var/spool/cron/crontabs/root- (non-existent user) The new cron program is complaining how unRAID is using its directory. You cannot do anything but ignore it and report it as a bug to lime-tech. Joe L. Quote Link to comment
mgworek Posted February 25, 2011 Author Share Posted February 25, 2011 Thanks for the quick reply! (Sorry for posting this under the wrong section. It should have gone under 5.0 section.) Quote Link to comment
limetech Posted February 26, 2011 Share Posted February 26, 2011 This has been fixed. Quote Link to comment
meoge Posted March 9, 2011 Share Posted March 9, 2011 I just updated from 5.0 Beta4 to 5.0 Beta6a and I'm still getting these messages every hour? Has this actually been fixed? Quote Link to comment
Joe L. Posted March 9, 2011 Share Posted March 9, 2011 I just updated from 5.0 Beta4 to 5.0 Beta6a and I'm still getting these messages every hour? Has this actually been fixed? The fixed version has not yet been deployed. Quote Link to comment
davekeel Posted April 14, 2011 Share Posted April 14, 2011 just googled the same error message and found this thread. Bit of a newbie and so maybe this question is stupid (apologies in advance if it is) but does this mean that the cron stuff doesn't work correctly if I get this message - eg Mover Schedule (which doesn't seem to work for me and I have to kick it off manually) plus the DS_Store and ._ file cleanup script? - which I have no way of telling whether it appears to be working or not?! THanks in advance D Quote Link to comment
AwesomeAustn Posted July 20, 2011 Share Posted July 20, 2011 I get this bug/issue also. I'm using 5.0-b9. So that's why the mover schedule doesn't work. I was wondering why. No big deal for me though. I can run the mover manually. Quote Link to comment
toby9999 Posted July 20, 2011 Share Posted July 20, 2011 See this thread... http://lime-technology.com/forum/index.php?topic=5568.msg131818#msg131818 Joe L. suggested changing the go script, although I would've thought it would have been better to update the Unmenu code instead (as a more permanent fix so people don't keep finding the error and wondering about it). Quote Link to comment
prostuff1 Posted July 20, 2011 Share Posted July 20, 2011 I get this bug/issue also. I'm using 5.0-b9. So that's why the mover schedule doesn't work. I was wondering why. No big deal for me though. I can run the mover manually. That error should not stop the mover from working. Quote Link to comment
prostuff1 Posted July 20, 2011 Share Posted July 20, 2011 See this thread... http://lime-technology.com/forum/index.php?topic=5568.msg131818#msg131818 Joe L. suggested changing the go script, although I would've thought it would have been better to update the Unmenu code instead (as a more permanent fix so people don't keep finding the error and wondering about it). Yes, the best way to fix this is to edit the .conf files. I know I have one to fix, but have not had the time to make the script work with both 4.7 and 5.0bX stuff. Quote Link to comment
pengrus Posted September 2, 2011 Share Posted September 2, 2011 Sorry to resurrect an old post, BUT... I'm on 5.0b10, and this error is not fixed. That error should not stop the mover from working. It's not the code that breaks the mover, it's Joe's fix. earlier versions of unRAID used that file for its management interface You can add a line like this to the end of your config/go script as follows if it bothers you. rm /tmp/crontab /var/spool/cron/crontabs/root- If you rm that line, as he suggests, you have to go back in and reestablish the mover schedule in the GUI. Which I guess you could write into the go script at the end, rm-ing the line, then maybe the code for the cron job that does the mover? Seems inelegant though. Is there another way? Quote Link to comment
mtruffa Posted September 6, 2011 Share Posted September 6, 2011 If only earlier versions used it, could that line not be removed in all of the conf files? I see it is at least 2-3 of them? Mike Quote Link to comment
stealth82 Posted January 25, 2012 Share Posted January 25, 2012 Somebody said it was fixed but I'm seeing it all over my log on 5.0-beta14. Jan 25 01:37:01 Tower crond[1161]: ignoring /var/spool/cron/crontabs/root- (non-existent user) Jan 25 02:37:01 Tower crond[1161]: ignoring /var/spool/cron/crontabs/root- (non-existent user) Jan 25 03:37:01 Tower crond[1161]: ignoring /var/spool/cron/crontabs/root- (non-existent user) Jan 25 04:37:01 Tower crond[1161]: ignoring /var/spool/cron/crontabs/root- (non-existent user) Jan 25 04:40:01 Tower logrotate: ALERT - exited abnormally. Jan 25 05:37:01 Tower crond[1161]: ignoring /var/spool/cron/crontabs/root- (non-existent user) Jan 25 06:37:01 Tower crond[1161]: ignoring /var/spool/cron/crontabs/root- (non-existent user) Jan 25 07:37:01 Tower crond[1161]: ignoring /var/spool/cron/crontabs/root- (non-existent user) Jan 25 08:37:01 Tower crond[1161]: ignoring /var/spool/cron/crontabs/root- (non-existent user) Jan 25 09:37:01 Tower crond[1161]: ignoring /var/spool/cron/crontabs/root- (non-existent user) Quote Link to comment
prostuff1 Posted January 25, 2012 Share Posted January 25, 2012 Somebody said it was fixed but I'm seeing it all over my log on 5.0-beta14. Jan 25 01:37:01 Tower crond[1161]: ignoring /var/spool/cron/crontabs/root- (non-existent user) Jan 25 02:37:01 Tower crond[1161]: ignoring /var/spool/cron/crontabs/root- (non-existent user) Jan 25 03:37:01 Tower crond[1161]: ignoring /var/spool/cron/crontabs/root- (non-existent user) Jan 25 04:37:01 Tower crond[1161]: ignoring /var/spool/cron/crontabs/root- (non-existent user) Jan 25 04:40:01 Tower logrotate: ALERT - exited abnormally. Jan 25 05:37:01 Tower crond[1161]: ignoring /var/spool/cron/crontabs/root- (non-existent user) Jan 25 06:37:01 Tower crond[1161]: ignoring /var/spool/cron/crontabs/root- (non-existent user) Jan 25 07:37:01 Tower crond[1161]: ignoring /var/spool/cron/crontabs/root- (non-existent user) Jan 25 08:37:01 Tower crond[1161]: ignoring /var/spool/cron/crontabs/root- (non-existent user) Jan 25 09:37:01 Tower crond[1161]: ignoring /var/spool/cron/crontabs/root- (non-existent user) What addon's are you running? Quote Link to comment
stealth82 Posted January 26, 2012 Share Posted January 26, 2012 Plex Media Server, mySQL, APC (but not running ATM). A couple of packages I compiled myself: Transmission, FreePOPs. A script - made by Joe L I think - scheduled for running parity check monthly. Quote Link to comment
prostuff1 Posted January 26, 2012 Share Posted January 26, 2012 Plex Media Server, mySQL, APC (but not running ATM). A couple of packages I compiled myself: Transmission, FreePOPs. A script - made by Joe L I think - scheduled for running parity check monthly. Not sure what would de causing it to happen every hour, unless you missed listing one, or plex is doing it. Quote Link to comment
sureguy Posted February 29, 2012 Share Posted February 29, 2012 A script - made by Joe L I think - scheduled for running parity check monthly. I think this script is the issue. Part of the script copies the generated crontab file to /var/spool/cron/crontabs/root- Commenting out, or removing this part of the script should fix this issue. Quote Link to comment
Joe L. Posted March 1, 2012 Share Posted March 1, 2012 A script - made by Joe L I think - scheduled for running parity check monthly. I think this script is the issue. Part of the script copies the generated crontab file to /var/spool/cron/crontabs/root- Commenting out, or removing this part of the script should fix this issue. That line was necessary in earlier versions of unRAID. As described, just delete the line that copies the crontab there. In earlier versions of unRAID lime-tech copied the crontab there to the root- file., and used that copy when changing other options rather than re-reading the crontab directly. If the copy was not made, the monthly schedule was wiped out if you made a config change in the unRAID web-management page. So now... just ignore the error in the log, it is harmless. At some point, when everyone is on the 5.whatever release, the config package can change. Quote Link to comment
ubergeek Posted October 14, 2013 Share Posted October 14, 2013 So I still get this, and am tryiing to troubleshoot why my disks keep spinning up (I have cache_dirs and sleep process that is accessing disks)....anyway can this error be to blame or how can I remove this crontab -root command from making its way into the system? Quote Link to comment
dgaschk Posted October 14, 2013 Share Posted October 14, 2013 So now... just ignore the error in the log, it is harmless. At some point, when everyone is on the 5.whatever release, the config package can change. The issue in in /boot/packages/monthly_parity_check.auto_install and /boot/packages/monthly_parity_check.manual_install The line cp /tmp/crontab /var/spool/cron/crontabs/root- should read: test -f /var/spool/cron/crontabs/root- && cp /tmp/crontab /var/spool/cron/crontabs/root- Adding the test solves the problem. Please update the distribution. P.S. This is not what's causing your disks to spin-up. Quote Link to comment
dcoens Posted October 22, 2013 Share Posted October 22, 2013 @dgaschk Should this be the script of the monthly_parity_check-sh then? #line would be removed. Also what does "test" do or is their a simpler line to replace it with #!/bin/sh crontab -l >/tmp/crontab grep -q "/root/mdcmd check" /tmp/crontab 1>/dev/null 2>&1 if [ "$?" = "1" ] then echo "# check parity on the first of every month at midnight:" >>/tmp/crontab echo "00 00 01 * * /root/mdcmd check NOCORRECT 1>/dev/null 2>&1" >>/tmp/crontab test -f /var/spool/cron/crontabs/root- && cp /tmp/crontab /var/spool/cron/crontabs/root- # cp /tmp/crontab /var/spool/cron/crontabs/root- crontab /tmp/crontab fi Quote Link to comment
dgaschk Posted October 22, 2013 Share Posted October 22, 2013 This was fixed in the distribution in 2011 but it does not update correctly. Uninstall the package, i.e., set it to not install on reboot, then reboot. Now installing the package will have the correct version. Enter "grep root- /boot/packages/*" to reveal any packages that have this issue. Any line that does not have the test indicates a package that needs to be uninstalled and then reinstalled after a reboot. The test prevents the creation of the root- crontab file on systems that have no need. Quote Link to comment
Recommended Posts
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.