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)

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.

Thanks for the quick reply!

 

(Sorry for posting this under the wrong section. It should have gone under 5.0 section.)

This has been fixed.

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?

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.

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

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.

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).

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.

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.

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?

 

 

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

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)

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?

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.

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.

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.

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.

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?

 

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.

@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

 

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.