ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
I've got a couple of questions that I need some advice on.
1. I need to have a piece of software running in the background as root, to make some system changes based on what it finds in a file. I was either going to run a script on startup and then sleep the script for a minute, or going to set the script to run from cron. Does anyone know of any performance issues to doing it either way?
2. I need to do some basic RS232 through the serial port. It will literally be one byte out and then reading a reply of one byte in. Can bash do serial comms, if so does anyone have some source code or a website with details?
I'm trying to stay away from doing some C, but if I have no choice then... I'd really like to do it in bash.
Actually, there is an extra overhead via cron because it has to create a process + env before it can execute it. From a user's pt of view it may not be obvious timing-wise, but it's definitely there.
I agree that for restart intervals of less than say 5 mins, running your own daemon is (prob) better; longer than that and I'd use use cron.
There's no hard + fast rule though ...
I thought it was going to be the other way round. As if you have several processes sleeping then you have several processes monitoring for wakeup, whereas cron would be just one process sleeping waiting to fire off the others.
Still I completed the job with sleep and the performance seems OK.
That's because a daemon is sleeping, then doing something (internally).
cron is a sleeping (not much) daemon that then creates an external standalone process+env for each entry at each time requested.
In kernel terms, process creation is much more expensive than 'activating' an already extant process.
The more jobs cron has to do and more often, the more 'creations' take place.
As I said:
From a user's pt of view it may not be obvious timing-wise, but it's definitely there.
For any one job/program, the diff is usually un-noticeable, but but the cumulative load will show (eg top) if there are a lot of jobs.