The script first sets the path that will be made available to all daemontools
run scripts,
blocks any input/output by redirecting standard
streams to /dev/null,
then shuts down any services that may already be running.

The script then starts svscan on the /service directory
with a clean environment,
redirecting stderr to stdout.
Any output from svscan is then piped into the command
listed on the last line of the script.

This brings us to the readproctitle command,
and the central object of interest in the discussion that follows.

The purpose of readproctitle
here is to give us some access to any error messages that may be generated
by a running svscan process.
The 400 dots that appear as the last argument to the command provide
readproctitle
with an in-memory buffer it uses to display whatever it reads from its standard input.
It is then possible to view this display with a process status listing using
the ps(1) command:

# ps -axww | grep readproctitle
[XXX sample output here]

The multiple ww option to ps will output the complete
width of the line, rather than truncate to fit your terminal.
If all is well,
all you will see is the readproctitle command line
with all those hundreds of dots.

When all is not well, however,
the dots following readproctitle
in the ps output will start
filling up with the error messages from svscan,
rolling in from the right.
Let's say one of your run scripts is not set executable,
a common error when you are adding a new service.
Once every second,
as supervise tries repeatedly to start the service,
an error message will be generated by svscan
and will start to scroll from right to left into the
readproctitlelog:

# ps -axww | grep readproctitle
[XXX sample output here]

That's the idea, anyway.

In practice, though, readproctitle has its downsides.
For one thing,
its behaviour is anomalous on the default
installation of at least one of our reference platforms
(FreeBSD 5.1).
Other problems:

output in ps listings is wrapped, truncated and hard to read

no timestamps; when did the error happen?

difficult to follow the log in real time, just ps over and over

old error messages aren't cleared

But if we abandon readproctitle,
how else are we going to know what's going on with svscan?

One answer is to simply use daemontools
multilog instead.

Here's the svscanboot script from above,
renamed to svscan-start, and
adapted to use multilog in place of readproctitle:

This gives immeasurably better feedback from svscan,
especially helpful in trouble-shooting and problem-solving for
the many services we will be installing along the djb way.

The svscan-start
script shown here may also take optional arguments;
see the notes in the script header.
This allows a system to start svscan
on additional service directories.
For example,
we sometimes setup a /service.test directory
for the purpose of testing and debugging new services,
before moving them into /service:

/usr/local/bin/svscan-start /service.test /var/multilog/svscan-test

notes

What's with the /command/pgrphack instead of /bin/csh
in the BSD startup?
pgrphack accomplishes the same thing as the C shell here,
which is to run svscan in a clean process state,
in its own process group,
and with a parent process ID of 1.

The difference is that the daemontools pgrphack
utility is specifically designed to accomplish this task,
and does it with an executable about one-tenth the size of the C shell.

freebsd and readproctitle

As mentioned above,
FreeBSD 5.x (release 5.1 in any case),
has problems with readproctitle.

The default installation will show this in a process status listing
with ps:

# ps -axww | grep readproctitle
397 con- S 0:00.61 (readproctitle)

Oops, where did the 400 dots go?
All you will ever see is the (readproctitle) in parentheses.
So much for getting any error reporting from svscan.