A program that ends but never ends Write a program that starts itself again when finishes.  

There should be no more than one instance of the program running at same time.  Not even for a slightest moment of time.

You can ignore any instance that is manually started by user during your cycle.  But your code should not do it in your restart cycle.

Program can start after any amount of time, as long as it is guaranteed that it starts again.

The only way to stop the cycle is to kill the process.

Your solution should not involve restarting of the environment (in which program is running, includes OS, machine, VM, shell etc).  Only your program is allowed to restart.
Bash script, 3 chars (Shortest, possibly the most elegant, though admittedly controversial)
$0&amp;

Simply places a new instance of itself in the background (new process), then quits.  The new instance likely will remain in the scheduler run-queue until the previous instance is done.
Warning - this is hard to kill, as the PID is continually changing.  Temporarily renaming the script file is probably the simplest way to break the cycle.
A single-core system is assumed.  Of course this is not realistic with Linux on modern bare-metal hardware, but it is easily configurable when running in a VM.  We could probably achieve a similar trick using taskset, but that would reduce the impact of the 3-char solution.
This answer bends the rules a little bit in that it applies a specific meaning of &quot;running&quot;.  There will be moments when the new process has been fork()ed and the old process is still alive - i.e. it may be possible to observe more than one PID.  However the new process will be placed on the Linux scheduler run-queue to wait for CPU cycles, while the existing process will continue to execute.  At this point all that needs to be done by the existing process is for bash itself to exit().  This does take a finite amount of time, though I'm fairly confident that it will be done way before the current timeslice/scheduler quantum is done.  Supporting evidence is the fact that bash starts up and shuts down in 2ms on my VM:

$ time bash -c :

real    0m0.002s
user    0m0.000s
sys 0m0.000s
$ 

Further supporting evidence that the new process does not actually run until the previous process is done can be seen in strace output:
strace -f -tt -o forever.strace bash -c ./forever.sh 

In the output, we see the original process has PID 6929.  We can see the fork() call (actually clone()), which returns a new PID of 6930.  At this point there are 2 PIDs, but only 6929 is currently running:

6929  12:11:01.031398 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f2f83ac49d0) = 6930
6929  12:11:01.031484 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
6929  12:11:01.031531 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
6929  12:11:01.031577 rt_sigprocmask(SIG_BLOCK, [CHLD], [CHLD], 8) = 0
6929  12:11:01.031608 rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0
6929  12:11:01.031636 rt_sigprocmask(SIG_BLOCK, [CHLD], [CHLD], 8) = 0
6929  12:11:01.031665 rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0
6929  12:11:01.031692 rt_sigprocmask(SIG_BLOCK, [CHLD], [CHLD], 8) = 0
6929  12:11:01.031726 rt_sigprocmask(SIG_SETMASK, [CHLD], NULL, 8) = 0
6929  12:11:01.031757 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
6929  12:11:01.031803 rt_sigprocmask(SIG_BLOCK, NULL, [], 8) = 0
6929  12:11:01.031841 read(255, "", 4)  = 0
6929  12:11:01.031907 exit_group(0)     = ?
6930  12:11:01.032016 close(255)        = 0
6930  12:11:01.032052 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0

Full strace output here.
We can see that 6930 does not issue any system calls until 6929 is completely done.  It is reasonable to assume that this means 6930 does not run at all until 6929 is done.  The perf utility would be the ultimate way to prove this.