This is a real-world worked example of setting up and running a service with
the nosh package.
The service is the ntpd daemon.

preparation

We start with some things that we pre-prepared, namely an unprivileged user for
the ntpd logging service to run as, and a directory for the logs
to go into.
Logging services are first class services in their own right under nosh, and
we will be setting up a logging service to take the standard output and
standard error of ntpd and record it in a set of auto-rotated
size-capped log files.
Remember that you are not required, with nosh, to have a 1:1 relationship
between logging daemons and the daemons whose output they are logging.
However:
First, this is the familiar modus operandi for those coming from other
daemontools-family daemon supervision systems.
Second, setting things up this way gives us the opportunity to demonstrate a
couple more of the mechanisms and features of the nosh toolset.

As you can see, our service bundles are going to be made in the current
directory, /var/sv/, and the log directory is
/var/log/sv/.
(If you want equivalent places for "local" services and log directories, the
obvious ones are of course /var/local/sv/ and
/var/log/local/sv.)

For this worked example we will be requiring the contents of the
nosh-exec, nosh-service-management,
nosh-systemd-shims, and nosh-bundles packages, as
well as a couple of things from the nosh source archive.
ntpd is in fact one of the pre-packaged service bundles in the
nosh-bundles package.
(The nosh-bundles package provides a whole load of
pre-built service bundles, and it is of course the goal that the world make
and publish more and more such service bundles.
In such a scenario one would skip the creation of the service bundle and
go straight to
the enabling and starting section.
But the purpose of this worked example is in part to show how one gets to a
running service from a systemd unit file with nosh.)
We've manually removed the pre-packaged bundle directories that we are
hand-rebuilding here.

making the log service

One of the things in the nosh package's source archive that we're using is the
cyclog@.service service template unit file, which we've copied
into the current directory.
This is a systemd service unit file — a templated one.
It invokes the nosh package's cyclog command to do the logging.
(Of course, you can use another logging program if you like.)

Using the convert-systemd-units subcommand of the
system-control command, we create a service bundle for the log
service, using ntpd as the template parameter.
(The nosh-systemd-shims package provides symbolic links that
make the system-control command available as
systemctl.
We use system-control here to emphasize that
convert-system-units is not a systemd subcommand.
We'll be using some systemd subcommands, and the name systemctl,
later on, though.)

This has generated an entire service bundle, in the current directory, named
cyclog@ntpd.
There's a full description of service bundles in the manual pages of the
system-control and service-manager commands;
so we won't go into that in depth here.
Of particular note are the service/ subdirectory and the
run program, which is a nosh script.
As you can see, the convert-systemd-units subcommand has
created a script that invokes several chain-loading commands to do the things
that the service unit specified, including changing user and working
directory.
It has also created some other scripts, not shown here because they are fairly
trivial in this case, in particular a restart program that always
exits success, to enact the service unit's Restart=always
setting.

(The setenv commands are there because of an undocumented feature
in systemd, an explanation of which can be found on the page about converting
systemd units in the nosh Guide.
The aren't necessary for, or even used by, cyclog.
But convert-systemd-units doesn't know that it isn't dealing with
a service that relies upon these undocumented features.)

making the main service

Now we come to making the main ntpd service.
Again, we're going to use a systemd service unit file taken from the nosh
package source archive — ntpd.service this time.

And again we convert it to a service bundle using the
convert-systemd-units subcommand.
(As an aside:
Note that it is -units plural because one of the things that it
can convert is a linked pair of a socket unit file and a service unit file.
It works out what you are converting from the suffix of the filename.
See the system-control manual page for the details.)

You may have noticed the presence of the
systemdWorkingDirectory=false setting in the service unit, and
the absence of a chdir command in the run script.
There is another undocumented systemd feature with respect to working
directories.
But since it's a marked difference from the daemontools world, there's an
explicit setting, an extension to the systemd service unit specification, for
turning it off for services that don't really need it and are quite happy
running with the daemontools conventions for working directories, which is in
fact most services.
(The number of services currently known to rely upon the undocumented systemd
behaviour stands at just one.)
Again, for more details see the aforementioned nosh Guide page.

A simple symbolic link serves to tell the system-control command, when it comes to tell the service manager to plumb the services together, where the log service is.

root /var/sv #ln -s ../cyclog@ntpd ntpd/log
root /var/sv #

enabling and starting the services

The nosh package supports running things the daemontools way, with the service manager started by some external system initialization system and services managed through symbolic links in a /service/ (or /etc/service/, or /var/service/ …) directory.
However, for this worked example we are using a system that has the nosh system manager running as process #1, and that has the "standard targets" installed from the nosh-bundles package.

We want to make sure that the services are "enabled", i.e. that they will be automatically brought up when the system is bootstrapped.
The command to do this is very familiar to those who have used systemd.
(With the systemv shims package installed, one can even use chkconfig on if one is so minded.)

Log services and main services are first-class citizens in nosh, remember.
They are both, to the service manager, just plain old services, that just happen to be plumbed together through a pipe in a particular way.
So one has to enable both of them.

The fileystem is the database in nosh.
So what enabling does is record in the "wants" list of the workstation service bundle (which is a standard target) pointers to the service bundles of the log and main services.
For details of the workstation target, and how it is started through the normal target at (normal mode) system bootstrap, see the nosh Guide and the system-control manual page.

We also want to bring up the services right now, i.e. to "start" them.
Again, this is a familiar command for those from the systemd world.
(And again, if one were so minded one could use service … start from the systemv shims package instead.)

root /var/sv #systemctl start ntpd cyclog@ntpd
root /var/sv #

The svstat command, familiar in turn to those who have used daemontools, shows that the services are now up.
(A similar svshow command is provided for generating output that is intended to be machine-readable, rather than human-readable as here.
And yes, systemctl show and systemctl status are also there if you have the systemd shim package installed.)

Because this machine is running the nosh system manager, there's a log
of the service manager's output (amongst other things) in
/run/system-manager/log/ which shows what the service manager
was told to do by systemctl.

As you can see, it loaded up both service bundles, plumbed them together with
a pipe (because of the symbolic link made earlier), ran their respective
start commands, and then ran their respective run
commands.

platform

And for those who haven't already figured it out from some offhand tidbits in the
aforegiven, here is a surprise.
This isn't a Linux system running this worked example, going from systemd unit
files to running services, at all.