Cron Daemon fails to load

FathisAeril · 2010-07-25 03:51:42

Title says it all really, if I try to start it manually after boot, all it says is

"STARTING CRON DAEMON: [FAIL]"

Checked the wiki, I am part of the users group,

I noticed 'crond" under /usr/sbin

it was owned by root, but group had NO privledges whatsoever, not sure if that is relevent though.

I have no idea where to start debugging failed daemons on this, so I am completly open to.. any suggestions.

JackH79 · 2010-07-25 04:10:16

Did you try to start cron as a user or as root?
Only root can do that.

FathisAeril · 2010-07-25 04:14:16

I've tried with standard user, sudo and su. it is in my rc.conf, and if I watch the boot process I can see it failling there too

JackH79 · 2010-07-25 04:36:04

You could try to delete your

/var/run/crond.pid

and try it again.

FathisAeril · 2010-07-25 04:44:39

Deleted it, re-ran:

sudo /etc/rc.d/crond start

and got

:: Starting Cron Daemon                                                  [FAIL]

Edit: made sure crond.pid hadnt gotten remade, rebooted and let it try on boot. It failed, tried it manually, failed again. =S

Last edited by FathisAeril (2010-07-25 04:52:49)

JackH79 · 2010-07-25 04:54:51

Just to make sure. Is your "/usr/sbin/crond"

chmod -R 700

?

Do you have anything in your "/var/log/crond"?

EDIT: Maybe really stupid, but could you check whether cron isn't running already?

ps -eaf | grep cron

Last edited by JackH79 (2010-07-25 04:57:20)

ewaller · 2010-07-25 05:13:43

FathisAeril wrote:

I noticed 'crond" under /usr/sbin
it was owned by root, but group had NO privledges whatsoever, not sure if that is relevent though.
.

JackH79 wrote:

Just to make sure. Is your "/usr/sbin/crond"
chmod -R 700
?

Well there's your problem...

edit: Fixed lost reference to JackH79

Last edited by ewaller (2010-07-25 05:16:24)

falconindy · 2010-07-25 05:34:40

When in doubt, open the rc.d script in a text file and execute the relevant commands by hand to figure out where it fails (and get some error msgs).

FathisAeril · 2010-07-25 06:07:57

After chmod'ing my /usr/sbin/crond, rebooted, checked to see if Cron is running and I get back

root 3291 1 0 01:56 ? 00:00:00 /usr/sbin/crond -S -l info

Which Im asusming is a good thing (Never really got the handle on daemons lol)

SOMETHING is still failing at boot though, I happened to notice that when I rebooted after doing the chmod, I assumed it was crond but since it successfully started it apparently wasnt that.

So I guess this is a two part post:

1) Why was the permissions for a package installed via pacman (not blaming pacman, just stating I installed it with pacman, not manually) messed up?

2) Anyway I can set a delay while the daemons are loading? I can see the red from "failed" I just can't get a good enough look at which daemon is failing because it immediately jumps to login.

JackH79 · 2010-07-25 06:22:17

1) Dunno

2) Have a look at http://wiki.archlinux.org/index.php/Dis … t_messages

falconindy · 2010-07-25 16:05:46

FathisAeril wrote:

After chmod'ing my /usr/sbin/crond, rebooted, checked to see if Cron is running and I get back
root 3291 1 0 01:56 ? 00:00:00 /usr/sbin/crond -S -l info

Which Im asusming is a good thing (Never really got the handle on daemons lol)

SOMETHING is still failing at boot though, I happened to notice that when I rebooted after doing the chmod, I assumed it was crond but since it successfully started it apparently wasnt that.
So I guess this is a two part post:
1) Why was the permissions for a package installed via pacman (not blaming pacman, just stating I installed it with pacman, not manually) messed up?
2) Anyway I can set a delay while the daemons are loading? I can see the red from "failed" I just can't get a good enough look at which daemon is failing because it immediately jumps to login.

1) Permissions were correct. From my working system:

-rwx------ 1 root root 26908 Feb 23 22:19 /usr/sbin/crond

Also, see below comment.
2) Scroll lock is your friend.

It didn't occur to me last night, but JackH79's suggestion of using chmod -R in a system directory is a bad bad bad bad bad ... BAD idea, especially for a single file. -R is recurse -- why would you do this?!. One misplaced character and you might be looking at a reinstall.

FathisAeril · 2010-07-25 16:38:42

Still failing on boot. Successfully booted into Arch.

Checked to see if cron was running

Output:

root      3288     1  0 12:32 ?        00:00:00 /usr/sbin/crond -S -l info
eric      3916  3762  0 12:34 pts/0    00:00:00 grep cron

Current File Permissions on crond:

-rwx------ 1 root root 32248 Feb 23 22:20 /usr/sbin/crond

Daemons line in rc.conf:

DAEMONS=(@syslog-ng network netfs @crond dbus hal ntpd alsa osspd cups usbmuxd gdm crond)

And it is still failing. Falcon, should I be worried about having set the permissions to 700 with the recursive flag? For the future scenarios, obviously, but for THIS scenario?

Edit: Noticed I had crond listed twice in daemons, I'll reboot and see if it successfully loads. But my question to falcon still stands

Last edited by FathisAeril (2010-07-25 16:41:24)

falconindy · 2010-07-25 16:48:16

crond listed twice in daemons was likely the issue. No doubt it's been running all along.

I wasn't there when you typed the command, but if everything is behaving then likely all is well. My concern is for a stray space, e.g.:

chmod -R 700 /usr /sbin/crond

You'll get an error about not finding /sbin/crond, but the stray space will hose your /usr directory, and hose it hard.

FathisAeril · 2010-07-25 16:51:58

ouch, okay noted. Yeah, considering it took me like a month to get Arch setup just how I wanted it... yeah i dont want to have to reinstall >_>

But If cron has been running all along, I'm kind of curious as to why my conky scripts isnt detecting upgradable packages. If anyone here is good with Python, I can post it in here or make a new thread just for that, doesnt make a difference to me either way

falconindy · 2010-07-25 17:00:43

Remember that cron runs in an environment that doesn't know about your PATH (and many other environment variables).

Why python for showing upgrades? Cron this in root's crontab:

0 * * * * pacman -Sy >/dev/null 2>&1

And put this in conky:

${execi 1200 pacman -Qu | wc -l}

Last edited by falconindy (2010-07-25 17:01:44)

FathisAeril · 2010-07-25 17:07:57

I had been following the Conky wiki, and one of the links for listing pacman upgrades was a python script that I liked because it sorted things by an 'importance' rating I could set, actually listed all the available packages, sorted them by repo. Things like that

FathisAeril · 2010-07-25 21:40:06

two Questions for you Falcon,

1) I happened to reboot and when I went into "crontab -e" as it says to edit / add crontabs, the original "0 * * * * pacman -Sy >/dev/null 2>&1" was gone. Is it still active? When I execute "crontab -e" it says its loading up a crontab under /tmp, to my knowledge, Linux clears out /tmp on every reboot. So I've lost the editted crontab?

2) With "${execi 1200 pacman -Qu | wc -l}" it correctly displayed 2 available updates, I updated, noticed it still said 2 updates available. So I redid "sudo pacman -Sy" and even tried "sudo pacman -Syy" to make it force-refresh the lists of packages, but conky still kept reporting 2 packages available. Any way you know of to change that?

falconindy · 2010-07-25 23:32:20

1) crontab files are not meant to be edited directly. The crontab file is copied to a temporary file, you edit that one, its checked for syntax correctness, and then overlaid on the old crontab. You did not lose your old crontab. Perhaps you meant to append a 'sudo' in there to look at root's crontab?

2) Sure. ${execi 1200 ...} means it's only running every 20 minutes. Either lower the interval or if you're feeling OCD, poke conky:

kill -HUP $(pidof conky)

That will force conky to reload its config.

Last edited by falconindy (2010-07-25 23:33:41)

FathisAeril · 2010-07-26 00:10:52

I had done

Su
crontab -e

But okay. Thanks falcon been a huge help. I'll prob just 'poke' conky in my sysupdate script.

JackH79 · 2010-07-26 00:36:34

falconindy wrote:

It didn't occur to me last night, but JackH79's suggestion of using chmod -R in a system directory is a bad bad bad bad bad ... BAD idea, especially for a single file. -R is recurse -- why would you do this?!

Fun?

No, seriously: I don't know. Just been doing a bunch of chmodding after copying ~ 500 gigs from an NTFS drive and it became kind of a habit. You are, of course , correct.

My humble apologies.

Arch Linux

#1 2010-07-25 03:51:42

Cron Daemon fails to load

#2 2010-07-25 04:10:16

Re: Cron Daemon fails to load

#3 2010-07-25 04:14:16

Re: Cron Daemon fails to load

#4 2010-07-25 04:36:04

Re: Cron Daemon fails to load

#5 2010-07-25 04:44:39

Re: Cron Daemon fails to load

#6 2010-07-25 04:54:51

Re: Cron Daemon fails to load

#7 2010-07-25 05:13:43

Re: Cron Daemon fails to load

#8 2010-07-25 05:34:40

Re: Cron Daemon fails to load

#9 2010-07-25 06:07:57

Re: Cron Daemon fails to load

#10 2010-07-25 06:22:17

Re: Cron Daemon fails to load

#11 2010-07-25 16:05:46

Re: Cron Daemon fails to load

#12 2010-07-25 16:38:42

Re: Cron Daemon fails to load

#13 2010-07-25 16:48:16

Re: Cron Daemon fails to load

#14 2010-07-25 16:51:58

Re: Cron Daemon fails to load

#15 2010-07-25 17:00:43

Re: Cron Daemon fails to load

#16 2010-07-25 17:07:57

Re: Cron Daemon fails to load

#17 2010-07-25 21:40:06

Re: Cron Daemon fails to load

#18 2010-07-25 23:32:20

Re: Cron Daemon fails to load

#19 2010-07-26 00:10:52

Re: Cron Daemon fails to load

#20 2010-07-26 00:36:34

Re: Cron Daemon fails to load

Board footer