I have a python (or ruby, doesn't really matter) script on a server which has to be reliable and run all the time. And if something happens and it crashes or gets frozen I need to know about that immediately. Previously I was thinking about another "script" such as a cron job which would check it up every minute by the means of Linux -- whether or not it's in the list of the active processes. However, now I think that even if it's the list of the active processes, it still might be frozen (it hasn't crashed yet, but it's about to).
Isn't that right? If so, I'm thinking of having it save some "heart-beat" data into a file every minute, because it's more reliable way to know whether or not it's up AND whether or not it's frozen, because if it's frozen it can't write into a file but still can be in the memory.
Your suggestions, should I go with that? Or just checking if its process in the memory (in the list of active processes) is perfectly enough?
If there are bad consequences when the script is not running (If there weren't, you probably wouldn't care, would you?), it might be most reliable to check for distinct symptoms of those consequences.
For example, if the script is a web server, have a monitoring service make requests to it and notify you whenever that fails.
If the bad consequences can be observed remotely or even off-site, have the monitoring remote, or if possible, off-site from the machine running your script. Why? If the consequences occur because your script stopped running because the machine running it died ... you wouldn't get notified if it was that same machine's task to notify you. If it's a different machine, you'll be made aware of the situation. Unless the data center burnt down. Then your monitoring service needs to be in a different data center for you to get notified.
There are paid and free monitoring service offers for publicly accessible servers, e.g. Uptime Robot for web servers, in case you don't want to develop and host the monitoring yourself.