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.

Any advice?

Thanks

I am using both. For processes which I like to run at intervals of 2 minutes or larger I use cron.

For shorter intervals (I have some scripts running at 20 seconds intervals) I use sleep.

I have never checked it, but I don't expect a performance penalty for one or the other. When a process is put to sleep, well... it sleeps and doesn't use any resources.

Cron is being run once every interval anyway, whether or not you program is called so I don't see any performance issues either.

Sleep in your own program offers finer granularity than cron so it is a logical choice for shorter intervals.

jlinkels

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.

Thanks

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.