On Wed, 20 Jan 2016 21:20:26 -1000 Joel Roth <[email protected]> wrote:
> Steve Litt wrote: > > On Wed, 20 Jan 2016 20:23:10 +0000 > > Rainer Weikusat <[email protected]> wrote: > > > > > Steve Litt <[email protected]> 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 _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
