Is using "while true" to keep a script alive a good idea?

Question

I'm just jumping into unix from a different world, and wanted to know if

while true
do
  /someperlscript.pl
done

The perl script itself internally has a folder/file watcher that executes when files are changed in the target location.

Is this (while true) a good idea? If not, what is a preferred robust approach?

TIA

EDIT : Since this seems to have generated a fair bit of interest, here is the complete scenario. The perl script itself watches a directory using a file watcher. Upon receiving new files (they arrive via rsync), it picks up the new one and processes it. Now the incoming files may be corrupt (don't ask.. coming from a raspberry pi), and sometimes the process may not be able to deal with it. I don't know exactly why, because we aren't aware of all the scenarios yet.

BUT - if the process does fail for some reason, we want it to be up and running and deal with the next file, because the next file is completely unrelated to the previous one that might have caused the error.

Usually I would have used some sort of catch all and wrapped the entire code around it so that it NEVER crashes. But was not sure for perl.

From what I've understood, using something like supervisord is a good approach for this.

Answer 1

That depends on how fast the perl script returns. If it returns quickly, you might want to insert a small pause between executions to avoid CPU load, eg:

while true
do
  /someperlscript.pl
  sleep 1
done

This will also prevent a CPU hog if the script is not found or crashes immediately.

The loop might also better be implemented in the perl script itself to avoid these issues.

Edit:

As you wrote the loop only purpose is to restart the perl script should it crashes, a better approach would be to implement it as a monitored service but the precise way to do it is OS dependent. Eg: Solaris smf, Linux systemd or a cron based restarter.

Answer 2

The other answers, about using inotify, are correct, but not an answer to this question.

A process supervisor, such as supervisord, upstart, or runit, is designed for exactly the problem of watching and restarting a service if it crashes.

Your distro probably comes with a process supervisor built in.

Answer 3

while true is fine as a general-purpose "loop forever" construction. As other answers say, the body of the loop shouldn't be empty, or become empty by virtue of the command inside the loop not working.

If you're using Linux, you may want to use a command like inotifywait, which makes the while loop much simpler:

while inotifywait -qqe modify "$DIRECTORY"
do
    process_the_directory "$DIRECTORY"
done

Here, the inotifywait command will sit and wait for a filesystem event to occur (in this example, when files in the directory are written to). At that point, it exits successfully and the body of the loop executes. It then goes back to waiting again. Because the inotifywait command waits for something to happen in the directory, it's much more efficient than continually polling the directory.

Answer 4

Move the while 1 into the perl script (Following @roaima suggestion)

#!/usr/bin/perl

 use Linux::Inotify2;

 my $inotify = new Linux::Inotify2 or die "unable to inotify: $!";

 $inotify->watch ("Dir", IN_MODIFY, ## or in_{acess,create,open, etc...}
   sub { my $e = shift;
     my $name = $e->fullname;
     ## whatever 
     print "$name was modified\n" if $e->IN_MODIFY;
  });

 1 while $inotify->poll;

Answer 5

When your perl script is intended to keep on running all the time, why use the while construction ? When the perl fails in view of some serious problem, the new perl script started by the while might crash just as hard. Again-and-again-and-so-on.
if you really want your perl started over, consider crontab and a script that first checks for running instances. This way your script will even be started after a reboot.

Answer 6

The while loop is really not a good idea. There's no escape there - it just runs forever - statically. Any number of things could change in the environment and it will not be affected - and this could be bad.

For example, if the shell executable responsible for that while loop is upgraded the kernel will not be able to release the disk space for the old version until that script quits because it needs to maintain the descriptor as long as it runs. And that is true for any files the shell might have open for whatever reason to run the loop - they will all be held open by this while loop for as long as it runs - forever.

And if, heaven forbid, there is a memory leak anywhere in the shell running that loop - even the most minute - it will simply continue to leak - statically. It will build unchecked and the only recourse is to forcefully kill it, then start it over just to do the same later.

This really isn't the way you should setup a backgrounded process - at least, not in my opinion. Instead, as I think, there should be a reset point - a refresh of the script and its state. The easiest way to do this is with exec. You can replace the current process with a new one - while maintaining the same PID - but still running a new process.

For example, if your perl script should return true after it has successfully handled a file modification in some monitored directory:

#!/bin/sh
trap 'rm -rf -- "${ldir%%*.}"' 0 INT
_exec() case    $#      in
        (0)     exec env -  "PID=$$" "ldir=${TMPDIR:-/tmp}/." \
                            "$0" "$@";;
        (*)     export "$@" "boff=0" "lmt=30"
                exec        "$0" "$@";;
        esac
[ "$PID" = "$$" ] || _exec
[ -w "$ldir" ]  &&
case    $ldir   in
(*.)    until   mkdir -- "$ldir"
        do      :& ldir=$ldir$$$!
        done    2>/dev/null
;;
(*)     until   /someperlscript.pl ||
                [ "$((boff+=1))"  -ge "$lmt" ]
        do      [ -d "$ldir" ]     &&
                sleep "$boff"      || ! break
        done
;;esac  &&      _exec ldir PID

...or something like that. Something that allows the basic machinery behind the loop to refresh every once in a while.

Answer 7

In general there is no problem using while true since it is a tiny test which is only executed after the perl script is terminated. Keep in mind that depending on which Linux/Unix variant you are using, the script might get terminated at logging off. In such case consider using the loop in a script and call it with nohup and put it in the background i.e. nohup myscript &

If the perl script terminates too often and causes CPU load than this load is accountable to the perl script and not the while true.

See also man nohup for details.

Answer 8

If you want to manage a process, you might want to look into a process manager to do so.

With many recent systems, you can use systemd to monitor your processes (which is one of the benefits of systemd over classical init-scripts). If your distro of choice doesn't use systemd, you could use daemontools or monit.

Answer 9

I upvoted a few of these answers, but I instinctively have the warmest feelings for @WalterA's answer. Well, I did until I created my own answer...

Personally, I'd tend to update the Perl script so that it writes a descriptive log entry about the failure and sends an alert to an administrator.

If the Perl script is meant to continue running, waiting for change events from the file system, why is it failing?

If it isn't failing, why are you concerned about wrapping it in a script to restart it infinitely?

If there's a configuration issue or some broken dependency that causes the Perl script to abort, simply restarting it over and over isn't likely to make it suddenly start working.

You know the definition of insanity, right? (doing the same thing over and over again, expecting a different result). Just saying. ;-)