:: Re: [DNG] Apparently Jessie has run…
Top Page
Delete this message
Reply to this message
Author: Steve Litt
Date:  
To: dng
Subject: Re: [DNG] Apparently Jessie has runit
On Wed, 20 Jan 2016 21:20:26 -1000
Joel Roth <joelz@???> wrote:

> Steve Litt wrote:
> > On Wed, 20 Jan 2016 20:23:10 +0000
> > Rainer Weikusat <rainerweikusat@???> wrote:
> >
> > > Steve Litt <slitt@???> writes:  
> > > > People aren't completely alone on run scripts: I can give them
> > > > any run scripts I'm using. Also, Runit run scripts are
> > > > *nothing* like sysvinit or OpenRC init scripts:    


[snip exact definition of "init scripts"]

> >
> > The actual files to which the S- and K-links point are the "init
> > scripts" to which I refer. So perhaps I used the wrong name for
> > them. Anyway, they're usually an unholy mess, usually over 40
> > lines, I think I remember seeing some go over 100.
>
> Hi Steve,
>
> How complicated is it to port such scripts to runit? Exim4's
> init.d script is 275 lines.
>
> Joel


Hi Joel,

According to http://smarden.org/runit/runscripts.html#exim , Runit's
run script for Exim should be:

=================================================
#!/bin/sh
exec /usr/local/sbin/exim -bdf -q30m
=================================================

Because the preceding doesn't contain "exec 2>&1", I would guess that
Exim does its own logging and doesn't need Runit to provide a log for
the Exim daemon.

Beyond that, I don't have the knowledge to answer your question in a
responsive manner.

So instead, let me answer a question you didn't ask...

It's often easier, quicker, and better engineering to build a Runit run
script with knowledge of the app being used as a daemon, a little
engineering, and a little trial and error.

Here's pseudocode for the typical Runit run script that runs as root,
doesn't need GUI capabilities, and needs no environment variables:

=================================================
#!/bin/sh
exec 2>&1
exec /path/to/daemon --run_in_forground other_arguments
=================================================

The "exec 2>&1" is necessary to log both stdout and stderr, so
if there's no logging you can delete it.

The process to be run must run in the foreground (unless you do some
runit kludges), must be exec'ed, and there can be no assumptions about
paths or environment variables, so all files must have full paths.

You can pretty much deduce the daemon's actual command line syntax by
looking at the 275 (or whatever) line sysvinit or OpenRC init script.
Precede that command with the word "exec ", and if by default the
command backgrounds itself, include the command line option to make it
keep itself in the foreground, and you're pretty much set.

To test it, open a new level of bash, make yourself root, delete all
environment variables, delete all paths, and then run the runscript and
see whether it does the job. If not, find out what's missing and put it
in.

If the daemon needs some environment variables set, just do this for
each one:

# export mykey=myvalue

If you need it to run as a user other than root, follow this sequence,
as root:

# sv down mydaemon

Insert " /usr/bin/chpst -udesired_user_id " immediately after the
"exec" on the line that executes the daemon.

# cd /etc/sv/mydaemon
# chown -R desired_user_id.desired_user_id supervise

# sv up mydaemon

Note that if mydaemon reads and writes files, those files might be user
root such that the user desired_user_id cannot access them. In that
case, properly chown those files.

Note that your commands might be a little different, ESPECIALLY the
directory /etc/sv, which is a Voidism. Nevertheless, adding a new
daemon is incredibly easy.

Runit isn't for everyone. It doesn't have the 30 years of
institutionalized support like sysvinit, and it doesn't have a million
dollars a year in corporate salary support like systemd, so there will
be some amount of fairly low level user responsibility. Nevertheless,
my experience with Void Linux tells me that it's quite easy for a
package to provide the necessary run script, and in Void, about 90% of
such run scripts work perfectly, without my modification. And for the
other 10%, the fixes are obvious.

SteveT

Steve Litt
January 2016 featured book: Twenty Eight Tales of Troubleshooting
http://www.troubleshooters.com/28