From: "depuis" <pascal.dupuis@worldonline.be>
Subject: runit integration
Date: Tue, 30 May 2006 09:57:52 +0200 [thread overview]
Message-ID: <J02JGG$CDDA2E0A143EE193321C00E5BEA706C5@scarlet.be> (raw)
Hello,
I've read yesterday the article on linux today about runnit - tried it - I
find it interesting, and I would like to comment a bit...
My background: linux hacker since 1996 (Slackware 3), today using debian etch
on a laptop, rebooting the system each day, so optimising the start phase is a
big win. Furthermore, I use laptop-net to configure programs and services
based upon the network environment: at home, at work, if a WIFI is available, ...
I think that runit should provide some compatibility mechanism with the
existing rc runlevels and /etc/init.d/ scripts. Maintainers carefully polished
those scripts, some are very elaborate, and providing a drop-in for these
scripts is a lot of work: compatibility issues, following the latest version,
and so on.
What does they have in common ? Most use the start-stop-daemon program in
order to control the processes. What about providing some alternative to this
program? But let's think first about what has to be adapted ? Not a lot.
Mostly program invocation. start-stop-daemon expects the called program to
detach(). In the runit context, this should be avoided. A possible solution is
to write a wrapper, like f.i. for gpm:
#!/bin/sh
sv start devfsd || exit 1
EXTRA_ARG="-D" /etc/init.d/gpm start
The idea is to define two environnement vars:
REMOVE_ARG which contains arguments that have to be removed from the final
command line ('--daemon' f.i.)
EXTRA_ARG is a supplemental arg which prevents the called program to detach
itself (program dependent)
The global idea would thus to provide some substitue for start-stop-daemon,
with some wrapper permitting to use the /etc/init.d script "as is". This
substitute would be a mix of runsv and chpst, as the start-stop-daemon can
alter the process state (-u, -g, ...). All the glue logic (this program must
wait that program before starting) would also be concentrated at the same level.
This way, the compatibility would be achieved as:
1) for each entry in /etc/rc2.d, place a symbolic link in /etc/runit/runsvdir/
default/ to a wrapper in /etc/sv
2) for each entry in /etc/init.d, provide a wrapper in /etc/sv wich add and
remove the required args so that the invoqued program does not detach,
together with the required dependencies on other programs.
This way, runit would be a replacement for sysvinit, minimising the migration
and maintenance burden.
I am not subscribed to this list, but I'll follow this discussion through the
archive.
Best regards
Pascal Dupuis
----------
Wordt ook lid van de Scarlet Club via een bestaande Scarlet klant en ontvang cadeaucheques twv EUR 50! Bezoek snel http://www.scarletclub.be
Devenez aussi membre du Club Scarlet via un client Scarlet existant et recevez des cheques cadeaux jusqu'a EUR 50! Surfez vite sur http://www.clubscarlet.be
next reply other threads:[~2006-05-30 7:57 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-30 7:57 depuis [this message]
2006-05-30 14:23 ` Charlie Brady
2006-05-30 23:40 ` Alex Efros
2006-05-31 5:04 ` Roy Lanek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='J02JGG$CDDA2E0A143EE193321C00E5BEA706C5@scarlet.be' \
--to=pascal.dupuis@worldonline.be \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).