General question:

On a Linux (Centos) server, if a process monitoring script run by cron is set to close with exit 1; rather than exit 0; on finding that everything is okay and that no action is needed, is that a mistake?

Or are there legitimate reasons for calling exit 1; instead of exit 0; on the "Everything's fine, no action needed" condition?

exit 0; on finding no problems seems to me to be more appropriate. But maybe there's something I'm not aware of. For example, maybe there's something specific to Cron? Or maybe there's a convention in process monitoring scripts that 'failure' means 'this script failed to need to fix a problem' (rather than what I would expect which is that exit 1; would mean 'the process being monitored has failed'?)

My specific case:

I'm looking at a process monitoring script written by my web hosting company. By process monitoring script, I mean a script executed by Cron on a regular basis that checks if an important system process is running, and if it isn't running, takes actions such as mailing an administrator or restarting the process.

Here's the (generalised) structure of their script, for a service running on port 8080 (in this case, Apache Tomcat):

SERVICE=$(/usr/sbin/lsof -i tcp:8080 | wc -l);

if [ $SERVICE != 0 ]; then
exit 1;
#take action

Seems simple enough even for someone with limited knowledge like me, except the exit 1; part seems odd. As I understand it, exit 0; closes a program and signifies to the parent that executed the program that everything is fine, exit n; where n>0 and n<127 signifies that there has been some kind of error or problem.

Here, their script seems to go against that rule - it calls exit 1; in the condition where everything is fine, and doesn't exit after taking remedial action in the problem condition.

To me, this looks like a mistake - but my experience in this area is limited. Are there cases where calling exit 1; in the "Everything's fine, no action needed" condition is more appropriate than calling exit 0;? Or is it a mistake?

Wider context is pretty simple. It's a Centos VPS, running Plesk. The script is being called by Cron via Plesk's "Scheduled tasks" Cron manager. There's no custom layer between Cron and this script that would respond in an unusual way to the exit call. It's a fairly average, almost out-of-the box Plesk-managed Centos VPS (in so far as there is such a thing). The process being monitored by this script is Apache Tomcat.


Your general analysis is right.

This doesn't sound directly "wrong" but definitely a "hackish" usage of cron semantics: usually if cron encounters a script to have an error it sends out the mail to the user (or whatever address is configured in the crontab).

I see this kind of script when people try to always get a mail when the script was run. I personally prefer the "regular" UNIX way of staying silent if everything is alright.

| improve this answer | |
  • There is this other school of thought who want to make sure that the monitoring script is really running. After all, is no news good news or is your mail server down? – chutz Dec 8 '12 at 17:05
  • That's what I use monitoring for. E.g. have Nagios watch the outcome of the job. – Theuni Dec 8 '12 at 17:06
  • 2
    So in layman's terms is this what you saying: using exit 1; when there are no problems is a bit like Homer Simpson's "Everything is okay" alarm. It's not exactly wrong, but it's a bit quirky, and not what many people would want. – user56reinstatemonica8 Dec 8 '12 at 17:17
  • Hahaha. Yes. Ex act ly. =) – Theuni Dec 8 '12 at 18:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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