I have a program that copies files from a network drive to a specific location per user. It needs to do this every 12 hours and it needs to start when the system (redhat linux) starts.

I was thinking about converting the program to a daemon and have it sleep for 12 hours, wake up, copy the files and go to sleep. However, is that an overkill?

What's better: a simple program that copies the files and then exits and call that from a CRON job every 12 hours or a daemon? what's better for the system?

thanks!

link|improve this question
feedback

1 Answer

up vote 8 down vote accepted

In my opinion, I would go with cron. Largely, because it's far less complicated and easier to implement.

The other option requires you putting effort into daemonizing the process, and creating a startup script for it. There's plenty that can go wrong there. And there's a solid chance that a bug or errant kill might cause the daemon to die. (are you going to make a cron process to check on your daemon?)

In cron, a good deal of that heavy lifting has already been handled by cron. It's a rocksolid daemon, it's got scheduling down pat, and if your script blows up, you'll get an E-Mail of the output.


--Christopher Karel

link|improve this answer
thanks for the help. I was thinking about creating the cron but I wasn't sure... – jessica Jun 30 '10 at 15:15
2  
If you were to use a daemon, there's no need to monitor it using a cron job. The daemon can be set to respawn. – Dennis Williamson Jun 30 '10 at 17:41
+1: The daemon thing is fraught. I wouldn't do it if you only need the program to run on an intermittent basis. – Satanicpuppy Jul 1 '10 at 13:51
+1: This is precisely the sort of thing that cron is intended for. The added complexity of writing a daemon adds nothing to the actual solution (at this stage at least) – Daniel Lawson Jul 5 '10 at 22:00
feedback

Your Answer

 
or
required, but never shown

Not the answer you're looking for? Browse other questions tagged or ask your own question.