OK, I'm not a newbie at linux, but I do have a noobish question. I've been trying to troubleshoot my crontab and whenever I try to enter something in it to be executed, it either never does or it gives me an issue with my perms. I've repeatedly checked my perms on crontab and all files in crontab including the programs running the scripts. Sadly, I never had any luck. So after working on this for a couple days now and not finding anything on google, I decided to post on the one forum that seems to be getting me closer to fixing this issue. OK, now for the details.

Error: Either no error and it doesn't run (The scripts all run fine manually and in the cron.daily, cron.hourly, etc. directories.)

If it does try to run it, it shows this:
Feb 16 12:59:01 buddha crond[3638]: (*system*) BAD FILE MODE (/etc/crontab)

Here's my crontab:

[LOCATION HIDDEN] Was used instead of the actual path for security reasons, but the path does exist on all of them.

Please let me know if you need any more information. Thanks again for your help in advance.

What's the files access rights then? /etc/crontab should have octal mode 0644. BTW it's not your crontab but the systems. Huge difference.


These are not std Centos /etc/crontab values, and "customizing" them should not ever be necessary:
These are standard values:

If you do not know something it is best not to fsck with it until you do (and even then). Maybe fixing the above will not automagically make your cronjobs run but it's best to reset conditions to "known good" values before troubleshooting. BTW, phpBFS is old (2006): consider using a supported, maintained application for blocking hosts like fail2ban, denyhosts, 'iptables -m recent' or equivalent. Having to restart Apache each 12 hours indicates problems far worse than cronjobs not working. Stopping APF every five minutes makes no sense.

1 members found this post helpful.

Well APF added that cron and I wasn't sure why, so I left it. It's good to know that I can take it out of the crontab so the server won't be burdened. As for apache restarting, I did that so that any new domains would be added in a timely manner and my customers would only have to wait for the remainder of the 12 hours and the propagation delay. Do you have another suggestion? My control panel I made doesn;t restart it right away so a blank page doesn't show. I guess I could change it to do so, but I haven't found a way around the blank page bit even when I make it restart after the script is finished. It's probably because it never sees apache to send it to the browser. =P

As for the modified globals, I wasn't sure if it was going to help my cause, so I just made it root. Does cron need to be 644? I mean, it's running some of the crons and customers can't directly access crontab. I have it as 777 so my CP can write to it. It's not dangerous with the server on lockdown and apache needs to be able to change it in the CP. I guess that's what the issue is with the system perms error, but if it's just a false positive, I'd like to leave it be if the system doesn't depend on it.

Oh, also if the system does depend on it, does crontab allow for include statements?

Sorry for the double post. I missed the edit link. I just wanted to let you know that this issue isn't resolved yet. I wasn't sure if it was clear or not from my last post.

I'm not sure that having your system crontab as 777 so your customers can write to it is a good idea. What is to stop them adding this?

Seriously - no unprivileged user should have access to the sytem crontab, they should be using their own.

As for restarting Apache to pickup additions, this should really be done by the software/script adding the virtual domain. Bumping apache when there are connected users could end session persistance and be a pretty unpleasant user experience - particularly if they happen to be using a shopping cart that empties on them as a result.

I would take the advice of unSpawn and set the system crontab back as it should be and make sure it runs:

As for permissions on it:
Forgive this if it sounds rude but your website claims a couple of things:
"award winning custom built server systems, high end security systems"
Which is really rather at odds with running an 4 year old unsupported hosting application that could be full of holes and trying to make the system crontab writeable by all. Given you are advertising to host porn it's very likely you will attract spammers, ratware hosters and the like - so you need to have the thing locked down tight. The second thing to draw is if anyone googles your hosting name, they may well end up getting hits to Linux Questions showing you asking basic crontab questions in a newbies section. This probably is not good for your professional reputation and digital fingerprint so you may just want to remove it. I appreciate you may think I'm being cruel and rude - I'm really not. It's good advice.

I know it's good advice. I'm not naive. I'll lock it down then I guess. It just seemed like a good idea because of the way the system is set up. It's not possible for the scrip I made to run anything as root and the file must exist in the user directory or lower. This ensures that no one can mess with it based on whet my system is designed for. However, they may find another breach I haven't accounted for and that does scare me. So, I'll just go with the user's own crontab.

As for this post, I think it is a better idea to just remove it to be on the safe side. Thanks for the help.

Could a mod please remove this post? Thanks in advance.

Shouldn't be hard to concoct something, be it shell or inotify-based. A nice question for a separate thread?


I'm sorry but I don't know what this has bearing on or what this means?


Custom values may introduce problems. If you change defaults then you must have a good reason for doing that. I'd suggest you reset things to defaults and then test things. You can always change back.


Yes.


/etc/crontab is for the system itself. Regular users, if allowed a shell, may have their own crontab (also see /etc/cron.deny, /etc/cron.allow). Virtual users (those that don't need a user account on the system) should not have a shell.


That's a good example of excessive access rights.


Says who?


Then make it have octal mode 0664 and ownership root.apache. Even better: make it have octal mode 0644 and ownership root.root and wrap changing things in a Sudo wrapper.



Crond doesn't handle includes that way, basically dirs like /etc/cron.d are for "includes".


//While not related to the topic itself I agree with spampig questioning the virtual (aka marketoid) vs actual state of things and his comments wrt image.

This issue has been resolved. I figured it out on my own. Thanks for your advice anyway. I changed the entire configuration of how I had things set up. Please remove this thread.

It'd be more helpful to everyone if you explained the fix so we can all learn,

OK, well I basically set the crontab file to 644 and took some of the entries out of it that weren't useful. APF was removed since I didn't realize that APF wasn't active and was in debug mode. I don't think it was smart of them to set it to debug mode initially. Also, Apache now reloads the domains as they're added instead of restarting, so I took that out as well. Last, I added a user cron for a non-root user and chowned it to the user with the same name as the file. (If you use myuser as the username, then use myuser as the file name.) So, I made it so that whenever someone adds a cron on using the CP, the script makes sure the file is in the user's directory and makes sure its safe, then it adds it to the file. The user cron file is set to 755.

So, why was it not running? I'm not sure. It probably was something with the perms though.