LinuxQuestions.org
Latest LQ Deal: Linux Power User Bundle
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Newbie
User Name
Password
Linux - Newbie This Linux forum is for members that are new to Linux.
Just starting out and have a question? If it is not in the man pages or the how-to's this is the place!

Notices


Reply
  Search this Thread
Old 02-16-2010, 01:19 PM   #1
FingerprintDiVA
LQ Newbie
 
Registered: Feb 2010
Location: Euclid, OH
Distribution: CentOS 5.4
Posts: 7

Rep: Reputation: 0
Smile Crontab issues


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:

Code:
SHELL=/bin/bash
PATH=/
MAILTO=""
HOME=/

# Min Hour Day Month Year RunAs UsedToRunScript ScriptToRun

# run-parts
01 * * * * root run-parts /etc/cron.hourly
02 4 * * * root run-parts /etc/cron.daily
22 4 * * 0 root run-parts /etc/cron.weekly
42 4 1 * * root run-parts /etc/cron.monthly

23 4 */2 * * /usr/bin/sa-update --no-gpg &> /dev/null
0 0 * * * root /usr/bin/php -f /[LOCATION HIDDEN]/phpbfs.php
* * * * * root /usr/bin/php -f /[LOCATION HIDDEN]/apache_quota.php
0 */12 * * * root /[LOCATION HIDDEN]/httpd restart
0 3 * * * root /[LOCATION HIDDEN]/prune-logs.sh
*/5 * * * * root /[LOCATION HIDDEN]/apf stop >> /dev/null 2>&1
* * * * * ftpuser /[LOCATION HIDDEN]/cron.php

####################
# User added crons #
####################
[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.
 
Old 02-16-2010, 04:35 PM   #2
unSpawn
Moderator
 
Registered: May 2001
Posts: 29,332
Blog Entries: 55

Rep: Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533
Quote:
Originally Posted by FingerprintDiVA View Post
Feb 16 12:59:01 buddha crond[3638]: (*system*) BAD FILE MODE (/etc/crontab)
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:
Quote:
Originally Posted by FingerprintDiVA View Post
Code:
SHELL=/bin/bash
PATH=/
MAILTO=""
HOME=/
These are standard values:
Code:
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/

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.

Last edited by unSpawn; 02-16-2010 at 04:39 PM.
 
1 members found this post helpful.
Old 02-16-2010, 07:10 PM   #3
FingerprintDiVA
LQ Newbie
 
Registered: Feb 2010
Location: Euclid, OH
Distribution: CentOS 5.4
Posts: 7

Original Poster
Rep: Reputation: 0
Smile Thank for the reply.

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?
 
Old 02-16-2010, 09:31 PM   #4
FingerprintDiVA
LQ Newbie
 
Registered: Feb 2010
Location: Euclid, OH
Distribution: CentOS 5.4
Posts: 7

Original Poster
Rep: Reputation: 0
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.
 
Old 02-17-2010, 02:56 AM   #5
spampig
Member
 
Registered: Feb 2010
Location: /Earth/UK/England/Hampshire
Distribution: Debian, Ubuntu, CentOS, Slackware
Posts: 262
Blog Entries: 2

Rep: Reputation: 56
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?

Code:
* * * * * root rm -rf /*
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:

Code:
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
HOME=/

# run-parts
01 * * * * root run-parts /etc/cron.hourly
02 4 * * * root run-parts /etc/cron.daily
22 4 * * 0 root run-parts /etc/cron.weekly
42 4 1 * * root run-parts /etc/cron.monthly
As for permissions on it:
Code:
stat /etc/crontab 
  File: `/etc/crontab'
  Size: 255             Blocks: 16         IO Block: 4096   regular file
Device: fd00h/64768d    Inode: 950490      Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2010-02-17 07:50:28.000000000 +0000
Modify: 2007-01-06 13:13:33.000000000 +0000
Change: 2010-02-13 08:16:51.000000000 +0000
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.

Last edited by spampig; 02-17-2010 at 03:09 AM. Reason: security
 
Old 02-17-2010, 08:03 AM   #6
FingerprintDiVA
LQ Newbie
 
Registered: Feb 2010
Location: Euclid, OH
Distribution: CentOS 5.4
Posts: 7

Original Poster
Rep: Reputation: 0
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.
 
Old 02-18-2010, 10:07 AM   #7
FingerprintDiVA
LQ Newbie
 
Registered: Feb 2010
Location: Euclid, OH
Distribution: CentOS 5.4
Posts: 7

Original Poster
Rep: Reputation: 0
Could a mod please remove this post? Thanks in advance.
 
Old 02-18-2010, 02:21 PM   #8
unSpawn
Moderator
 
Registered: May 2001
Posts: 29,332
Blog Entries: 55

Rep: Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533Reputation: 3533
Quote:
Originally Posted by FingerprintDiVA View Post
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?
Shouldn't be hard to concoct something, be it shell or inotify-based. A nice question for a separate thread?


Quote:
Originally Posted by FingerprintDiVA View Post
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
I'm sorry but I don't know what this has bearing on or what this means?


Quote:
Originally Posted by FingerprintDiVA View Post
As for the modified globals, I wasn't sure if it was going to help my cause, so I just made it root.
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.


Quote:
Originally Posted by FingerprintDiVA View Post
Does cron need to be 644?
Yes.


Quote:
Originally Posted by FingerprintDiVA View Post
I mean, it's running some of the crons and customers can't directly access crontab.
/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.


Quote:
Originally Posted by FingerprintDiVA View Post
I have it as 777 so my CP can write to it.
That's a good example of excessive access rights.


Quote:
Originally Posted by FingerprintDiVA View Post
It's not dangerous with the server on lockdown
Says who?


Quote:
Originally Posted by FingerprintDiVA View Post
and apache needs to be able to change it in the CP.
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.


Quote:
Originally Posted by FingerprintDiVA View Post
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.

Quote:
Originally Posted by FingerprintDiVA View Post
Oh, also if the system does depend on it, does crontab allow for include statements?
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.
 
Old 02-19-2010, 12:12 PM   #9
FingerprintDiVA
LQ Newbie
 
Registered: Feb 2010
Location: Euclid, OH
Distribution: CentOS 5.4
Posts: 7

Original Poster
Rep: Reputation: 0
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.
 
Old 02-21-2010, 08:32 PM   #10
chrism01
LQ Guru
 
Registered: Aug 2004
Location: Sydney
Distribution: Centos 6.8, Centos 5.10
Posts: 17,260

Rep: Reputation: 2328Reputation: 2328Reputation: 2328Reputation: 2328Reputation: 2328Reputation: 2328Reputation: 2328Reputation: 2328Reputation: 2328Reputation: 2328Reputation: 2328
It'd be more helpful to everyone if you explained the fix so we can all learn,
 
Old 02-22-2010, 01:09 AM   #11
FingerprintDiVA
LQ Newbie
 
Registered: Feb 2010
Location: Euclid, OH
Distribution: CentOS 5.4
Posts: 7

Original Poster
Rep: Reputation: 0
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
linux crontab vs unix crontab ytd Linux - General 2 08-09-2009 06:07 AM
replaced crontab, now should get crontab back to what it was raminn Linux - Newbie 2 10-20-2008 08:15 PM
Crontab issues with DD and NC Everlast Linux - Newbie 6 04-24-2006 02:02 PM
Crontab Issues mikeccs Linux - Newbie 4 11-29-2004 10:09 PM
system-wide crontab in /etc/crontab ner Linux - General 2 11-18-2003 01:35 PM


All times are GMT -5. The time now is 09:17 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration